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converged Services and Protocols for Advanced Networking (TISPAN). 



ETSI 



1 3 ETSI TS 1 83 043 V3.4.1 (201 1 -04) 



Scope 



The present document defines call control protocols and procedures for use in the IMS-based PSTN/ISDN Emulation 
subsystem based on the Media Gateway Control Protocol (MEGACO), the Session Initiation Protocol (SIP), and the 
associated Session Description Protocol (SDP). 

NOTE: The present document relies on the architectural framework defined in TS 182 012 [3] for IMS-based 
PES Emulation and may need to be updated once the open issues identified in the present document are 
resolved. 

The present document is applicable to: 

the interface between the User Equipment (UE) and the Call Session Control Function (CSCF); 

the interface between the Access Gateway Control Function (AGCF) and the Media Gateway Function 
(MGF); 

the interface between the Access Gateway Control Function (AGCF) and the Call Session Control Function 
(CSCF); 

the interface between the CSCF and any other CSCF; 

the interface between the CSCF and an Application Server (AS); 

the interface between the CSCF and the Media Gateway Control Function (MGCF); 

the interface between the S-CSCF and the Multimedia Resource Function Controller (MRFC); 

the interface between the CSCF and the Breakout Gateway Control Function (BGCF); 

the interface between the BGCF and the MGCF; 

the interface between the BGCF and any other BGCF; 

the interface between the CSCF and an external Multimedia IP network; 

the interface between the CSCF and the IBCF. 

1.1 Not supported services and capabilities 

The present document depends on supported capabilities by some other specifications. This situation may lead to some 
limitations. See clause 6.3.5 and annex I. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vahd at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[I] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description 
[3GPP TS 23.506 Release 8, modified]". 

[3] ETSI TS 182 012: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based PSTN/ISDN Emulation Sub-system (PES); 
Functional architecture". 

[4] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229)". 

[5] ETSI TS 183 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); H.248 Profile Version 3 for controlling Access and Residential 

Gateways". 

[6] ETSI TS 124 628: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Common Basic Communication procedures using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.628)". 

[7] ETSI TS 124 647: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Advice Of Charge (AOC) using IP Multimedia (IM) 
Core Network (CN) subsystem (3GPP TS 24.647)". 

[8] ETSI TS 124 610: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication HOLD (HOLD) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.610)". 

[9] ETSI TS 124 604: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication Diversion (CDIV) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.604)". 

[10] ETSI ES 200 659-3: "Access and Terminals (AT); Analogue access to the Public Switched 

Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) 
services; Part 3: Data link message and parameter codings". 

[II] Void. 

[12] ETSI ETS 300 738: "Human Factors (HP); Minimum Man-Machine Interface (MMI) to public 

network based supplementary services". 

[13] ITU-T Recommendation H.248. 23: "Gateway control protocol: Enhanced Alerting packages". 

[14] ITU-T Recommendation H.248. 26: "Gateway control protocol: Enhanced analog lines packages". 

[15] IETF draft-ietf-sipping-config-framework-17: "A Framework for Session Initiation Protocol User 

Agent Profile Delivery". 

[16] IETF RFC 4240: "Basic Network Media Services with SIP". 

[17] IETF RFC 4733: "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals". 

[18] IETF RFC 3842: "A Message Summary and Message Waiting Indication Event Package for the 

Session Initiation Protocol (SIP)". 

[19] IETF RFC 3966: "The tel URI for Telephone Numbers". 
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[20] ETSI EN 383 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Interworking between Session Initiation Protocol (SIP) and 
Bearer Independent Call Control (BICC) Protocol or ISDN User Part (ISUP) [ITU-T 
Recommendation Q. 1912.5, modified]". 

[21] IETF RFC 2805: "Media Gateway Control Protocol Architecture and Requirements". 

[22] ITU-T Recommendation H. 248.1: "Gateway control protocol". 

[23] ITU-T Recommendation G.71 1 : "Pulse code modulation (PCM) of voice frequencies". 

[24] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)". 

[25] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity 

within Trusted Networks". 

[26] ETSI TS 124 606: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Message Waiting Indication (MWI) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.606)". 

[27] ETSI TS 124 611: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Anonymous Communication Rejection (ACR) and 
Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification (3GPP TS 24.611)". 

[28] ETSI ES 282 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Charging management [Endorsement of 3GPP TS 32.240 
Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 and 
3GPP TS 32.299 Release 7, modified]". 

[29] ITU-T Recommendation Q.763: "Signalling System No. 7 - ISDN User Part formats and codes". 

[30] ITU-T Recommendation Q.764: "Signalling System No. 7 - ISDN User Part signalHng 

procedures". 

[31] ITU-T Recommendation Q.1980.1: "The Narrowband Signalling Syntax (NSS) - Syntax 

definition" . 

[32] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Interworking between the IP Multimedia (IM) Core 
Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163)". 

[33] ETSI TS 124 623: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Extensible Markup Language (XML) Configuration 
Access Protocol (XCAP) over the Ut interface for Manipulating Simulation Services 
(3GPP TS 24.623)". 

[34] ETSI EN 300 356 (all parts): "Integrated Services Digital Network (ISDN); Signalling System 

No.7 (SS7); ISDN User Part (ISUP) version 4 for the international interface". 

[35] ITU-T Recommendation Q.735.3: "Stage 3 description for community of interest supplementary 

services using Signalling System No. 7 : Multi-level precedence and preemption". 

[36] ITU-T Recommendation Q.735.6: "Stage 3 description for community of interest supplementary 

services using Signalling System No. 7 : Global Virtual Network Service (GVNS)". 

[37] ITU-T Recommendation Q.736.3: "Stage 3 description for charging supplementary services using 

Signalling System No. 7 : Reverse charging (REV)". 

[38] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[39] ETSI EN 301 798: "Services and Protocols for Advanced Networks (SPAN); Anonymous Call 

Rejection (ACR) Supplementary Service; Service description". 

[40] ETSI TS 183 036: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification". 
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[41] ETSI EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling 

System No. one (DSSl) protocol; Signalling network layer for circuit-mode basic call control; 
Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[42] ETSI TS 129 658: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; TISPAN; SIP Transfer of IP Multimedia Service 
Tariff Information; Protocol specification (3GPP TS 29.658)". 

[43] ETSI ES 283 035: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e2 interface based 
on the DIAMETER protocol". 

[44] ETSI TS 124 615: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication Waiting (CW) using IP Multimedia 
(IM) Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.615)". 

[45] IETF RFC 3023: "XML Media Types". 

[46] Void. 

[47] ETSI TS 124 642: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Completion of Communications to Busy Subscriber 
(CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) 
Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.642)". 

[48] ITU-T Recommendation V.152: "Procedures for supporting voice-band data over IP networks". 

[49] ITU-T Recommendation T.38: "Procedures for real-time Group 3 facsimile communication over 

IP networks". 

[50] IETF RFC 5939: "Session Description Protocol (SDP) Capability Negotiation". 

[51] IETF draft-ietf-mmusic-sdp-media-capabilities: "SDP media capabilities Negotiation". 

[52] IETF draft-schwarz-mmusic-sdp-offer-answer-examples: "Session Description Protocol (SDP) - 

Revised Offer/ Answer Protocol (SDPCapNeg & MediaCapNeg) - Offer/ Answer Examples". 

[53] IETF RFC 3388: "Grouping of Media Lines in the Session Description Protocol (SDP)". 

[54] IETF RFC 3389: "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)". 

[55] ITU-T Recommendation G.168: "Digital network echo cancellers". 

[56] ITU-T Recommendation T.30: "Procedures for document facsimile transmission in the general 

switched telephone network". 

[57] ETSI EN 300 659-1: "Access and Terminals (AT); Analogue access to the Public Switched 

Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) 
services; Part 1: On-hook data transmission". 

[58] ETSI EN 300 659-2: "Access and Terminals (AT); Analogue access to the Public Switched 

Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) 
services; Part 2: Off-hook data transmission". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol 

(XCAP)". 

[i.2] IEEE 1003.1-2004: "Standard for information technology - portable operating system interface 

(POSIX). Shell and utilities". 
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[i.3] IETF RFC 4488: "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit 

Subscription". 

[i.4] IETF RFC 3515: "The Session Initiation Protocol (SIP) REFER Method". 

[i.5] ETSI TR 183 072: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Emulation Services for PSTN Modem Calls". 

[i.6] ETSI EG 201 973-2: "Access and Terminals (AT); Public Switched Telephone Network; Support 

of legacy terminals by Broadband IP networks and equipment; Part 2: Analogue PSTN terminals". 

[i.7] IETF RFC 355 1 : "RTP Profile for Audio and Video Conferences with Minimal Control". 

[i.8] IETF RFC 3362: "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

access gateway: gateway device that interworks a significant number of analogue lines/ISDN accesses (directly or via 
an V5 Access Network) to a packet network and is located at the operator's premises 

NOTE: An access gateway can take the form of a Media Gateway (A-MGW) or a Voice over IP Gateway 
(A-VGW). 

loose coupling: on-hook and flash-hook are analyzed in the AGCF/VGW; much like a simulation endpoint would 
operate 

Media Gate Way (MGW): gateway device acting at the media/transport plane, providing the functions of an MGF as 
defined in ES 282 001 [1] 

NOTE 1 : A MGW may additionally relay signalling traffic, in which case it also provides the functions of an SGF 
as defined in ES 282 001 [1]. 

NOTE 2: In the present document. Media Gateway refers both to Access Gateways and to Residential Gateways, to 
form an A-MGW, or an R-MGW, respectively. 

Media Gateway Controller (MGC): See ITU-T Recommendation H.248.1 [22]. 

T.38/G3: Is a T.38 endpoint that supports G3FE, but excludes the ITU-T Recommendation T.30 [56] V.34 procedures. 

NOTE: Also known as "T.38/V.17 G3" or "T.38/non-V.34 G3" endpoint type. 

T.38/V.34G3: Is a T.38 endpoint that supports G3FE and includes the ITU-T Recommendation T.30 [56] V.34 
half-duplex procedures. 

NOTE: Also known as "Super G3" (SG3) T.38 endpoint type. 

residential gateway: gateway device that interworks a small number of analogue lines/ISDN accesses 

NOTE: A residential gateway typically contains one or two analogue lines or ISDN basic accesses and is located 
at the customer premises. A residential gateway can take the form of a Media Gateway (R-MGW) or a 
Voice over IP Gateway (R-VGW). 

tight coupling: on-hook and flash-hook are interpreted by the AS 

Voice over IP GateWay (VGW): SIP-based gateway device that implements both a media gateway function and a 
media gateway controller function as defined in RFC 2805 [21] and supports the provision of voice based services to 
analogue hnes/ISDN accesses 
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NOTE: A Voice over IP Gateways (VGW) whether acting as an Access Voice over IP Gateway (A-VGW) or as a 
Residential Voice of IP Gateway (R-VGW) plays the role of a PES Endpoint (i.e. acting as an IMS UE 
with regards to the P-CSCF). 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3PTY Three-Party Service 

ACR Automatic Communication Rejection 

AGCF Access Gateway Control Function 

AOC Advice Of Charge 

AS Application Server 

AVP Audio Video Profile (RTP) 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

CCBS Call Completion on Busy Subscriber 

CCNR Call Completion on No Reply 

CD Call Deflection 

CDP Charging Determination Point 

CFB Call Forwarding on Busy 

CFNR Call Forwarding on No Reply 

CFU Call Forwarding Unconditional 

CGP Charging Generation Point 

CLE Connectivity session Location and repository Function 

CLIP Calling Line Identification Presentation 

CLIR Calling Line Identification Restriction 

CN Core Network 

COLP connected Line identification Presentation 

COLR connected Line identification Restriction 

CONF CONFerence 

CPG Call ProGress 

CSCF Call Session Control Function 

CUG Closed User Group 

CW Call Waiting 

DC Direct Current 

ECT Explicit Call Transfer 

FM Feature Manager 

FoIP Facsimile over IP (T.38) 

FQDN Fully Qualified Domain Name 

G3FE Group 3 Facsimile Equipment 

GoS Grade of Service 

GPL Generic Parameter List 

GVNS Global Virtual Network Service 

HOLD call HOLD 

lAF Internet-Aware Fax (T.38 device) 

IBCF Interconnection Border Control Function 

I-CSCF Interrogating CSCF 

IM IP Multimedia 

I-MGCF Incoming - MGCF 

IMS IP Multimedia core network Subsystem 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

MCID Malicious Call Identification 

MEGACO MEdia GAteway COntrol protocol 

MGC Media Gateway Controller 

MGCF Media Gateway Control Function 

MGF Media Gateway Function 

MGW Media GateWay 

MLPP Multi-Level Precedence and Pre-emption 

MRF Multimedia Resource Function 
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MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

MWI Message Waiting Indicator 

NCL Negotiated Configuration (Codec) List 

NGN Next Generation Network 

NSS Narrowband Signalling Syntax 

O-MGCF Outgoing - MGCF 

P-CSCF Proxy - CSCF 

PCL Preferred Configuration (Codec) List 

PES PSTN Emulation Subsystem 

PSTN Public Switched Telephone Network 

REV REVerse Charging 

RFC Request For Comments 

RTP Real-time Transport Protocol 

S-CSCF Serving CSCF 

SDP Session Description Protocol 

SGF Signalling Gateway Function 

SIP Session Initiation Protocol 

SOC Switch Order Command 

SUB SUBaddressing 

TAS Terminal Alerting Signal 

TP Terminal Portability 

UA User Agent 

UE User Equipment 

UPSF User Profile Server Function 

URI Uniform Resource Identifier 

UUS User-to-User Signalling 

VBD VoiceBand Data 

VBDoIP VoiceBand Data over IP (V.152) 

VGW Voice over IP Gate Way 

VMS Voice Mail System 

XCAP XML Configuration Access Protocol 

XML extensible Markup Language 



IMS-based PSTN Emulation Subsystem (PES) 
overview 



4.1 



General 



The IMS-based PSTN/ISDN Emulation Subsystem (PES) supports the emulation of PSTN/ISDN services for 
analogue/ISDN terminals connected to the TISPAN NGN, through residential gateways or access gateways. The 
IMS-based PES functional architecture is defined in [3]. 

Emulating PSTN/ISDN services using the IMS-based PES architecture assumes that the logic of the service to be 
emulated resides in one or more application servers playing the role of a PES application server. 

Analogue/ISDN terminals are connected to residential gateways or access gateways using standard analogue/ISDN 
interfaces. The protocol running on interfaces between these gateways and the PES is either the gateway control 
protocol according to ITU-T Recommendation H. 248.1 [22] (PI reference point) or the session initiation protocol (SIP) 
according to RFC 3261 [38] (Gm reference point), depending on the type of gateway: 

• H.248-based voice over IP media gateway (MGW); or 

• SIP-based voice over IP gateway (VGW). 

Media gateways incorporate the Media Gateway Functional (MGF) entity identified in ES 282 001 [1] and are 
controlled by an Access Gateway Control Function (AGCF), at the PI reference point. Media gateways supporting 
ISDN accesses shall also incorporate a Signalling Gateway Function (SGF) as defined in ES 282 001 [1]. 
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Further details on the architecture are available in TS 182 012 [3]. 

Annex C illustrates the use of the PES for implementing usual PSTN services identified in EG 201 973-2 [i.6]. 

Annex F specifies the interworking of analogue terminals using overlap dialling with SIP overlap signalling. 

4.2 URI and address assignments 

In case multiple subscribers are connected to the same gateway, there is no need to allocate a private user identity per 
subscriber. Whether a private user identity is allocated per gateway, group of subscribers or per subscriber is a matter 
for each operator to decide. 

The AGCF stores private user identities and public user identities in a local data base. 

4.3 AGCF and VGW session and registration processing model 
4.3.1 General 

Figure 1 illustrates the session processing model used by the AGCF and VGW functional entities. An AGCF is 
modelled as comprising H.248 Media Gateway Controller (MGC), Feature Manager (FM), and SIP UA functionality. 
An AGCF interfaces to a Media Gateway (MG) and also to the S-CSCF (via PI and Mw reference points respectively). 

A functional modelling of the VGW contains an entity similar to H.248 Media Gateway Controller, a Feature Manager, 
a SIP UA, and MGW functionality. The VGW interfaces to the P-CSCF using the Gm reference point. 

NOTE: The internal architecture of functional entities is not standardized. Any internal interfaces are hidden and 
not testable. 

The SIP UA functionality provides the interface to the other components of the IMS -based architecture. It is involved in 
registration and session processing as well as in event subscription/notification procedures with application servers. 

The MGC functionality enable the session processing functionality to interface with existing line signalling such as 
analogue signalling or DSSI. 

Session and registration processing in the AGCF or VGW involves two halves: H.248 based MGC processing and SIP 
User Agent (UA) processing (see figure 1). MGC processing focuses on the interactions with the media gateway 
functions, while SIP UA processing focuses on the interactions with the IMS components. The Feature Manager (FM) 
coordinates the two processing activities. 
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-m 



Figure 1 : AGCF/VGW session processing model 



4.3.2 Conventions 

The communication between the Feature Manager, MGC and SIP User Agent components of the AGCF or VGW is 
modelled using primitives. This modelling is used as an ease to describe the AGCF and VGW behaviour and is not 
intended to constrain implementations. 

The following primitives are defined: 

Service-Change: This primitive is used by the MGC in the PES access point or PES endpoint for reporting the 
ServiceChange event to the Feature Manager. 

Register-Request: This primitive is used by the Feature Manager for requesting the SIP User Agent to initiate 
appropriate SIP registration procedures on behalf of emulation users. 

Deregister-Request: This primitive is used by the Feature Manager for requesting the SIP User Agent to 
initiate appropriate SIP deregistration procedures on behalf of emulation users. 

Session- Attempt: This primitive is used to notify the Feature Manager of an outgoing call attempt. 

Setup-Request: This primitive is used to request establishment of a session. 

Setup-Response: This primitive is used to confirm the establishment of a session. 

Session-Update: This primitive is used to update a session description. 

Session-Progress: This primitive is used to report intermediate events during session establishment. 

Session-Release-Request: This primitive is used to request the release of a session. 

Session-Release-Confirm: This primitive is used to confirm release of a session. 

Session-Release-Suspend: This primitive is used to suspend a session release procedure. 

Session-Resume: This primitive is used to indicate that a session in the release phase is to be resumed. 

Feature-Request: This primitive is used to report the occurrence of a service feature activation request from the 
user. 
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• Charging-Indication: This primitive is used to report the occurrence of a charging event. 

• Service-Notification: This primitive is used to report the occurrence of a service notification. 

The Feature Manager processes the above internal events received from the MGC side and request the SIP UA to 
generate the appropriate SIP messages based on the mapping described in table 1 . 

Table 1 : Mapping from MGC side to SIP UA side 



Internal primitive 


SIP message 


Setup Request 


INVITE 


Session Progress (alerting) 


180 Ringing 


Setup Response (no Answer) 


480 (Temporary Not Available) 


Setup Response (answer) 


200 OK (INVITE) 


Setup Response (busy) 


486 Busy Here 


Setup Response (failure indication) 


4XX or 6XX response depending on the 
actual failure 


Feature Request 


re-INVITE/ INVITE 


Session Release Request 


BYE or CANCEL (note) 


Session Release Confirm 


200K (BYE) or 200 OK (CANCEL) (note) 


NOTE: This mapping applies when the CANCEL requests cancels a pending 
INVITE request. 



The Feature Manager processes SIP messages received from the SIP UA side and transmit appropriate internal 
primitives to the MGC side, based on the mapping described in table 2. 

Exceptions to the above mapping applicable to calls originating from an analogue line are specified in the following 

clauses. 

Table 2: Mapping from SIP UA side to MGC side 



SIP message 


Internal primitive 


INVITE 


Setup Request 


183 Session Progress 


Session Progress 


180 Ringing 


Session Progress(alerting) 


200 OK 


Setup Response (answer) 


603 (Decline), 408 (Request Timeout), 
480 (Temporary Not Available) 


Setup Response (no answer) 


Other 4xx, 5xx, 6xx 


Setup Response (failure indication) 


486 (Busy Here), 600 (Busy Everywhere) 


Setup Response (busy) 


re-INVITE with SDP, UPDATE 


Session Update (SDP) 


REFER 


Without "m" parameter contained in the 
Request URI: Session Update (refer). 
Request URI contains the "m" 
parameter: Setup-Request (refer) 


INFO (charging) or NOTIFY (charging) 


Charging Indication 


NOTIFY (other) 


Service Notification 


BYE or CANCEL (note) 


Session Release Request 


200 OK (BYE) or 200 OK (CANCEL) 
(note) 


Session Release Confirm 


NOTE: This mapping applies when the CANCEL requests cancels a pending 
INVITE request. 



In case of ISDN access, the feature manager procedures shall conform to TS 183 036 [40]. 
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5 Protocol using SIP and SIP events for PES 

5.1 Introduction 

This clause identifies the functional entities of the IMS -based PES architecture [3] that play a specific role in the 
implementation of PES services with regards to SIP processing. 

5.2 Functional Entities 

5.2.1 User Equipment (UE) 

Conventional IMS UEs do not exist in PES. In PES, the User Equipment comprises one or more analogue/ISDN 
terminals and may include the residential gateway to which they are connected. This residential gateway may be an 
H.248-controlled media gateway or a Voice over IP Gateway (VGW). Voice over IP Gateways (VGW) appear as 
conventional IMS UEs with regards to the P-CSCF, i.e. they play the role of a SIP user agent from SIP perspective. 
Analogue/ISDN terminals are not visible to PES network entities. 

NOTE: Analogue/ISDN terminals - "user equipment" - can also be connected to PES via an Access Gateway. 

For the purpose of the PES, a residential VGW, in line with the behaviour of all VGWs, shall implement the role of a 
PES endpoint as described in clause 5.3.1. 

5.2.2 Access Gateway Control Function (AGCF) 

For the purpose of the PES, the AGCF shall implement the role of the PES access point as described in clause 5.3.2. 

The AGCF is part of the trust domain. 

The AGCF entity encompasses the functionality of an H.248 Media Gateway Controller (MGC) as defined in ITU-T 
Recommendation H.248. 1 [22] and of a SIP User Agent as defined in RFC 3261 [38]. Within the AGCF, the MGC and 
SIP UA components are coordinated by a Feature Manager entity whose logical behaviour is described in annex B. 

The AGCF shall appear to other CSCFs as if it were a P-CSCF. 

5.2.3 Application Server (AS) 

For the purpose of the PES, the AS shall implement the role of a PES application server, as described in 
clause 5.3.3. 

NOTE: The PES architecture does not require that all application servers involved in sessions initiated/addressed 
by/to PES users adhere to the procedures prescribed for the PES application server role. Any application 
server that conforms to TS 182 006 [2] may be involved in such sessions. 

5.2.4 Media Resource Function Controller (MRFC) 

For the purpose of the PES, an MRFC shall implement the role of the PES announcement server as described in 
clause 5.3.4. 

5.2.5 Media Gateway Controller Function (MGCF) 

For the purpose of the PES, the MGCF shall implement the role of a PES interworking application as described in 
clause 5.3.5. 

5.2.6 Interconnection Border Control Function (IBCF) 

For the purpose of the PES, the IBCF shall implement the role of a PES Interconnection Application as described in 
clause 5.3.6. 
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5.2.7 Voice over IP gateway (VGW) acting as Access Gateway 

For the purpose of the PES, an access VGW, in line with the behaviour of all VGWs, shall implement the role of the 
PES end point as described in clause 5.3.1. 

The VGW entity encompasses the functionality of a Media Gateway Controller (MGC), Media Gateway (MG) and a 
SIP User Agent as defined in RFC 3261 [38]. Within the VGW, the MGC, MGW and SIP UA components are 
coordinated by a Feature Manager entity whose logical behaviour is described in annex B. 

NOTE: The internal interfaces of the VGW are not standardized or testable. 

5.3 Role 

5.3.1 PES Endpoint 

5.3.1.1 General 

In addition to the procedures specified in the rest of clause 5.3.1, the PES endpoint shall support the procedures 
specified in TS 124 229 [4] and TS 124 628 [6] appropriate to an IMS UE. 

5.3.1 .2 Subscription for profile delivery 

The PES Endpoint shall subscribe to the "ua-profile" event defined in [15] and support the Profile document defined in 
annex A of the present document and optionally to the "message-summary" event defined in RFC 3842 [18]. 

The subscription may be implicit or explicit. If explicit subscription is required, the identity of the AS acting as the 
profile delivery server where the subscription request shall be sent may be provisioned in the functional entity in which 
the PES endpoint is implemented. Alternatively, the user profile may contain an appropriate Initial Filter Criteria on 
SUBSCRIBE messages that ensure that such requests are sent to the AS acting as the profile delivery server. 

On receipt of a NOTIFY request reporting the "ua-profile" event and including an XML document with a Dial Tone 
Management element, the PES end point shall set the current dial tone to the value indicated by the dial-tone-pattern 
element received in the present document. 

On receipt of a NOTIFY request reporting the "message-summary" event with a "Messages-Waiting" field set to "yes", 
the PES end point shall: 

• Save the current dial tone value and set the current dial tone to the message waiting tone. 

• Send a Message Waiting Indicator message (see ES 200 659-3 [10]) to the calling user. 

If the "message-summary" event is received with a "Messages-Waiting" field set to "no", the PES end point shall restore 
the previous current dial tone. 

The contents of the SUBSCRIBE request shall be as follows: 

• The value of the Request-URI shall be set to a provisioned value or to a public user identity associated to the 
line/access to which the profile applies. 

• The From and To header shall be set to the public user identity associated to the line/access to which the 
profile applies. 

• The Accept header shall include the "application/simservH-xml". 

• The Event header shall be set to the "ua-profile" event package. 

• The Event parameters shall be set as follows: 

The "profile-type" parameter shall be set to "user". 
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NOTE 1 : The public user identity contained in the Request-URI and in the From and To header fields may be built 
from the line or access identifier (e.g. line-identifier@pes.operator.com) or be a directory number 
obtained by the PES Endpoint through provisioning or at registration in case of line-based registration. 

The "vendor", "model" and "version" parameter values shall be set to values specified by the implementer of the 
functional entity in which the PES endpoint is implemented, as specified in [15]. 

NOTE 2: When implicit subscription is used, the PES endpoint should also be prepared to accept "unsolicited" SIP 
NOTIFY requests with the "message-summary" event. 

5.3.1.3 Registration procedures 

The allocation of private and public user identities is left to each operator to decide. Two approaches are identified: 

• Group-based registration: One private user identity is assigned to a group of subscriber. A temporary public 
user identity is associated with this private user identity. Real public user identities representing the 
subscribers connected to the analogue or ISDN ports of the VGW are registered using implicit registration 
procedures defined in TS 124 229 [4]. 

• Line-based registration: A private user identity and one more public user identities are associated with each 
analogue port/ISDN access connected to the VGW. 

The two approaches are not mutually exclusive. 

Depending on the registration method used, the To and From headers in the REGISTER request shall be set to a SIP 
URI that contains the temporary public user identity associated with the group to be registered or a temporary public 
user identity associated with the line/access to be registered or a permanent public user identity (i.e. directory number) 
associated with the line/access to be registered. 

NOTE: The temporary public user identity may be provisioned on the VGW or in case of line based registration 
may be built from the line or access identifier (e.g. line-identifier@pes.operator.com). 

5.3.1.4 Charging procedures 

A PES Endpoint supporting advice of charge services shall support the INFO method and shall accept MIME bodies of 
type "application/vnd.etsi.aocH-xml" (see annex E), indicating the versions of the AOC XML Schema it supports. If the 
PES Endpoint receives an INFO request including a body with AOC information, then the Content-Type header field 
shall include "application/vnd.etsi.aocH-xml", the MIME type associated with AOC information (see annex E), and the 
"sv" or "schemaversion" parameter's value shall be set to the versions of AOC XML Schema that can be used to 
validate the AOC information XML body (part). One of the versions - of the MIME type associated with AOC 
information (see clause 9.1) - indicated shall correspond with a value of the version attribute of the <schema> XML 
element of an AOC XML Schema (see annex E). If the "sv" and "schemaversion" parameter are absent, the PES 
Endpoint shall assume that version 1 of the XML Schema for the AOC information XML body is supported. If both the 
"sv" and "schemaversion" parameters are present, then the PES Endpoint shall use the "sv" parameter. 

In multiple call leg scenarios like three way conversation or conference calls the PES Endpoint shall process charging 
information received from the PES Application server as described in clause 5.3.3.6: 

• The charging information shall be assumed to be received for each call leg separately from the PES 
Application Server. The PES Endpoint has to combine the AOC information received from the PES 
Application Server. 

• As a network operator option the charging information received may be assumed as a combined representation 
applying to all call legs. The PES Endpoint simply applies the last received charging information to the served 
user. 

5.3.1.5 Outgoing Call 
5.3.1.5.1 General 

Calls initiated by a PES user via a PES end point shall operate following the UE call origination procedures defined in 
TS 124 229 [4]. 
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When the role of the PES end point is played by an A-VGW connecting lines sitting at different locations, the PES end 
point should include a P-Access-Network-Info header with a dsl-location parameter set to a provisioned value 
associated to the calling line. 

When the "priority -line" flag included in the user profile is set to "enabled", the PES end point overrides any active 
overload control procedure that may apply to the call. 

5.3.1 .5.2 Procedures for analogue lines 

On receipt of a non-empty Setup-Request the PES Endpoint shall send an INVITE request with the call destination in 
the Request-URI, an SDP Offer for a voice call. The INVITE shall include a P-Preferred-Identity header field set to the 
default identity associated with the analogue termination where the off-hook event was detected. If the 
P-Preferred-Identity is not sent then the PES Endpoint shall ensure that the From header contains the equivalent 
identity. 

If line-based registration has been used this default identity is the first one received in the P-Associated-URI header. 

If group-based registration has been used, this default identity is derived from the analogue termination identifier 
through a provisioned mapping table or by creating a URI from the analogue termination identifier 
(e.g. termination-id@pes.operator.com). In the later case, it is assumed that the PES AS will replace the contents of the 
P-Asserted-Identity with a meaningful public user identity (i.e. a Directory number). 

On receipt of an empty Setup-Request (i.e. without explicit destination information) the PES Endpoint shall build and 
send an INVITE Request as described above except that the Request-URI shall be set to a provisioned value 
(e.g. nodial@pes.operator.com ). It is up to the PES Application Server to reject the call by sending back an appropriate 
response code or to substitute the Request-URI with a subscriber-specific default value before forwarding the INVITE 
requests towards a destination. 

5.3.1 .5.3 Procedures for ISDN access 

The procedures specified TS 183 036 [40] apply. 

If line-based registration is used, the PES Endpoint shall set the P-Preferred-Identity header according to the calling 
party number received from the ISDN interface, as specified in TS 183 036 [40]. 

If group-based registration is used the PES Endpoint shall set the P-Preferred-Identity header to the default identity 
associated with the ISDN access where the call originates from. This default identity is either a directory number 
derived from the ISDN access identifier through a provisioned mapping table or a URI created from the ISDN access 
identifier (e.g. isdn-access-id@pes.operator.com). In the later case, it is assumed that the PES AS will replace the 
contents of the P-Asserted-Identity with a meaningful public user identity (i.e. a Directory number). 

NOTE; When the P-Preferred-Identity is set to an identity representing the ISDN access, the actual end user 
identity is still available in the From header as specified in TS 183 036 [40]. 

When performing interworking with the DSS.l protocol, as specified in TS 183 036 [40], the PES end point shall 
indicate support of the application/vnd.etsi.pstn-nxml MIME type. 

5.3.1 .5.4 Use of Overlap Signalling (Optional) 

If Overlap Signalling is supported between the PES Endpoint and the originating PES Application Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annex F is 
dependent on national or network operator option. For ISDN Access the procedures specified in 
TS 183 036 [40] apply. 

5.3.1.6 Terminating Call 

5.3.1.6.1 General 

Calls to a PES user via a PES end point shall operate following the UE call termination procedures defined in 

TS 124 229 [4]. The contents of the To header field is used to fetch the termination to which the call shall be delivered. 
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If an "m" parameter is received in an INVITE request containing the values "BS or NR", this indication for the Call 
Completion recall may be used to inform the user about this event. This indication may be used to select a ring pattern 
conforming to a "distinctive" ring signal. 

5.3.1 .6.2 Use of Overlap Signalling (Optional) 

If Overlap Signalling is supported between the PES Endpoint and the terminating PES Application Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annex F is 
dependent on national or network operator option. For ISDN Access the procedures specified in 
TS 183 036 [40] apply. 

5.3.1 .6.3 Receipt of a REFER request outside a session 

If a REFER is received outside a dialogue, this may occur in case of a recall procedure, the PES Endpoint acts 
according the method parameter in the Refer-To header with simultaneous consideration of the URI of the Refer-To 
header. In this context if a "m" parameter is received containing the values "BS or NR", this indication for the Call 
Completion recall may be used to inform the user about this event. This indication may be used to select a ring pattern 
conforming to a "distinctive" ring signal. 

5.3.1 .7 Supplementary services configuration 

5.3.1.7.1 Analogue lines 

Analogue subscribers can control their supplementary services using service code commands as defined in 

ETS 300 738 [12] included in the user part of the Request-URI of an INVITE message. Further details are provided in 

annex C. 

5.3.1.7.2 ISDN lines 

ISDN subscribers can configure supplementary services using procedures applied at either the Gm reference point or 
the Ut reference point. 

In the case of the Ut reference point, HTTP PUT, HTTP GET or HTTP DELETE requests are used in accordance with 
RFC 4825 [i.l] and the supplementary services application usage specified in TS 124 623 [33]. 

In case of the Gm reference point two procedures are available: 

• Use of service code commands as for analogue subscribers, when ISDN stimulus procedures are used by the 
end user terminal. 

• Use of the MESSAGE method when ISDN functional procedures are used by the end user terminal. 

The MESSAGE method is used to convey the service related information to the relevant target. The information to 
configure a service is embedded in an XML instance document contained in the MESSAGE request as specified in 
TS 183 036 [40]. 

The P-Preferred-Identity shall be set as specified in clause 5.3.1.5 for an INVITE request. 

The To and From headers shall be set to the public user identity associated to the supplementary service action. This 
public user identity may be built from the line or access identifier (e.g. line-identifier@pes.operator.com) or be a 
directory number obtained by the PES Endpoint through provisioning or at registration in case of line-based 
registration. 

When receiving a MESSAGE request conveying a response to an ISDN supplementary service interrogation procedure 
(see TS 183 036 [40]), the PES endpoint shall look for the In-Reply-To header field and evaluate its contents to identify 
the initial MESSAGE request to which it is responding. 
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5.3.2 PES Access Point 

5.3.2.1 General 

In addition to the procedures specified in the rest of clause 5.3.2, the behaviour of the PES access point shall be 
equivalent to the concatenation of the behaviour of a UE and a P-CSCF entity, as defined in TS 124 229 [4] and 
TS 124 628 [6]. 

NOTE: The above statement does not require AGCF implementations to execute UE and P-CSCF procedures in 
sequence. 

5.3.2.2 Subscription for profile delivery 

On receipt of a NOTIFY request reporting the "message-summary" event with a "Messages-Waiting" field set to "yes", 
the PES access point shall: 

• Save the current dial tone value and set the current dial tone to the message waiting tone. 

• Send a Message Waiting Indicator message (see ES 200 659-3 [10]) using the procedures described in 
clause 7.3.1.5. 

Other procedures specified in clause 5.3.1.2 apply. 

5.3.2.3 Registration Procedures 

The following IMS parameters are assumed to available in a local data base: 

• a private user identity; 

• a public user identity; and 

• a home network domain name to which SIP REGISTER requests are addressed. 

The allocation of private and public user identities is left to each operator to decide. Two approaches are identified: 

• Group-based registration: One private user identity is assigned to a group of subscribers. Groups should not 
contain subscribers connected to different gateways. A temporary public user identity is associated with this 
private user identity. Public user identities representing the subscribers connected to the analogue/ISDN ports 
controlled by the AGCF are registered using implicit registration procedures defined in TS 124 229 [4]. 

NOTE 1 : The list of implicitly registered identities is provisioned on the UPSF and transmitted to the assigned 

S-CSCF during registration. This list may be in the form of one or more individual Tel URIs or SIP URIs 
with a user=phone qualifier and/or one or more wildcarded Public User Identities. 

• Line-based registration: A private user identity and one or more public user identities are associated with each 
analogue port/ ISDN access connected to the MGWs controlled by the AGCF. 

A combination of the two approaches may also be used. 

The PES access point populates REGISTER messages as follows: 

a) an Authorization header, with the username field, set to the value of the private user identity associated with 
the subscriber or subscriber group to be registered; 

b) a From header set to the SIP URI that contains the temporary public user identity associated with the group to 
be registered or the public user identity associated with the subscriber to be registered; 

c) a To header set to the SIP URI that contains the temporary public user identity associated with the group to be 
registered or the public user identity associated with the subscriber to be registered; 

NOTE 2: The temporary public user identity may be provisioned on the AGCF or in case of line based registration 
may be built from the line or access identifier (e.g. line-identifier@pes.operator.com). 

d) a Contact header set to include SIP URI(s) containing its own IP address in the hostport parameter or FQDN; 
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e) a Via header set to include the IP address or FQDN of the AGCF in the sent-by field; 

f) an Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as 
the value desired for the duration of the registration; 

NOTE 3: A greater value may be used as an operator's option when registration applies to access gateways. 

g) a Request-URI set to the SIP URI of the domain name of the home network associated with the group to be 
registered; 

h) the Supported header containing the option tag "path"; 

i) a Path header including an entry containing: 

the SIP URI identifying the AGCF; 

an indication that requests routed in this direction of the path (i.e. from the S-CSCF to the AGCF) are 
expected to be treated as for the terminating case. This indication may e.g. be in a parameter in the URI, 
a character string in the user part of the URI, or be a port number in the URI. 

j) a Require header containing the option tag "path"; 

k) a P-Charging-Vector header with the icid parameter populated as specified in ES 282 010 [28]; 

1) the P-Access-Network-Info header set as specified for the DSL access network technology; and 

m) a P-Visited-Network-ID header field, with the value of a pre-provisioned string that identifies the network 
where the AGCF resides. 

When group registration applies, the content of the P-Associated-URI header received in the response to the 
REGISTER request is ignored. 

When the PES Access Point controls an A-MGW, the dsl-location parameter within the P-Access-Network-Info header 
field is set to a provisioned value associated to the private user identity. When the PES Access Point controls an 
R-MGW, the dsl-location parameter is set to a value retrieved from the NASS using the protocol defined in 
ES 283 035 [43], as described in TS 124 229 [4]. 

NOTE 4: If multiple public user identities are associated to the gateway termination, a default user identity is used. 
The default user identity is provisioned on the AGCF on a per-line basis within each registration group. 

5.3.2.4 Originating Call Control procedures 

5.3.2.4.1 General 

Calls initiated by a PES user via a PES access point shall operate following the concatenation of UE call origination and 
P-CSCF procedures as defined in TS 124 229 [4]. 

When the PES Access Point controls an A-MGW, the dsl-location parameter within the P-Access-Network-Info header 
field is set to a provisioned value associated to the line or to the media gateway it is connected to. When the PES Access 
Point controls an R-MGW, the dsl-location parameter is set to the value retrieved from the NASS during registration as 
described in TS 124 229 [4]. If this information is no longer available, the PES Access Point may query the CLE on a 
per-call basis. 

When the "priority-line" fiag included in the user profile is set to "enabled", then the PES Access Point overrides any 
active overload control procedure that may apply to the call. 

5.3.2.4.2 Procedures for analogue lines 

On receipt of a non-empty Setup-Request the PES access point shall send an INVITE request with the call destination in 
the Request-URI, an SDP Offer set according to the information received from the MGF and a P-Asserted-Identity 
header field set according to the default identity associated with the analogue termination where the off-hook event was 
detected. 

If line-based registration has been used this default identity is the first one received in the P-Associated-URI header. 
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If group-based registration has been used, this defauh identity is derived from the analogue termination identifier 
through a provisioned mapping table or by creating a URI from the analogue termination identifier 
(e.g. termination-id@pes.operator.com). In the later case, it is assumed that the PES AS will replace the contents of the 
P-Asserted-Identity with a meaningful public user identity (i.e. a Directory number). 

On receipt of an empty Setup-Request (i.e. without explicit destination information) the PES access point shall build 
and send an INVITE Request as described above except that the Request-URI shall be set to a provisioned value 
(e.g. nodial@pes.operator.com ). It is up to the PES Application Server to reject the call by sending back an appropriate 
response code or to substitute the Request-URI with a subscriber-specific default value before forwarding the INVITE 
requests towards a destination. 

5.3.2.4.3 Procedures for ISDN access 

The procedures specified TS 183 036 [40] apply. 

If line-based registration is used, the PES Access Point shall set the P-Asserted-Identity header according to the calling 
party number received from the ISDN interface, as specified in TS 183 036 [40]. The PES Access Point shallverify that 
this identity is included in the P-Associated-URI header and otherwise overrides it with the first URI received in the 
P-Associated-URI. 

If group-based registration is used the PES Access Point should set the P-Asserted-Identity header to the default identity 
associated with the ISDN access where the call originates from. This default identity is either a directory number 
derived from the ISDN access identifier through a provisioned mapping table or a URI created from the ISDN access 
identifier (e.g. isdn-access-id@pes.operator.com). In the later case, it is assumed that the PES AS will replace the 
contents of the P-Asserted-Identity with a meaningful public user identity (i.e. a Directory number). 

When performing interworking with the DSS.l protocol, as specified in TS 183 036 [40], the PES access point shall 
indicate support of the application/vnd.etsi.pstn-nxml MIME type. 

5.3.2.4.4 Use of Overlap Signalling (Optional) 

If Overlap Signalling is supported between the PES Endpoint and the originating PES Application Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annex F is 
dependent on national or network operator option. For ISDN Access the procedures specified in 
TS 183 036 [40] apply. 

5.3.2.5 Terminating Call Control procedures 

5.3.2.5.1 General 

Terminating calls received by a PES access point shall operate following the UE call termination procedures defined in 
TS 124 229 [4]. The contents of the To header field is used to fetch the termination to which the call shall be delivered. 

When the PES Access Point controls an A-MGW, the dsl-location parameter within the P-Access-Network-Info header 
field is set to a provisioned value associated to the line or to the media gateway it is connected to. When the PES Access 
Point controls an R-MGW, the dsl-location parameter is set to the value retrieved from the NASS during registration as 
described in TS 124 229 [4]. If this information is no longer available, the PES Access Point may query the CLE on a 
per-call basis. 

When performing interworking with the DSS.l protocol, as specified in TS 183 036 [40], the PES access point shall 
indicate support of the application/vnd.etsi.pstn-nxml MIME type. 

When the "priority-line" flag included in the user profile obtained via Profile delivery XML schema is set to "enabled", 
then the PES Access Point overrides any active overload control procedure that may apply to the call. 

If an "m" parameter is received in an INVITE request containing the values "BS or NR", this indication for the Call 
Completion recall may be used to inform the user about this event. This indication may be used to select a ring pattern 
conforming to a "distinctive" ring signal. 
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5.3.2.5.2 Use of Overlap Signalling (Optional) 

If Overlap Signalling is supported between the PES Access Point and the terminating PES Application Server the 
Overlap Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within 
annex F is dependent on national or network operator option. For ISDN Access the procedures specified in 
TS 183 036 [40] apply. 

5.3.2.5.3 Receipt of a REFER request outside a session 

If a REFER is received outside a dialogue, this may occur in case of a recall procedure, the PES Endpoint acts 
according the method parameter in the Refer-To header with simultaneous consideration of the URI of the Refer-To 
header. In this context if a "m" parameter is received containing the values "BS or NR", this indication for the Call 
Completion recall may be used to inform the user about this event. This indication may be used to select a ring pattern 
conforming to a "distinctive" ring signal. 

5.3.2.6 Charging procedures 

A PES access point supporting advice of charge services shall support the INFO method and shall accept MIME bodies 
of type "application/vnd.etsi.aocH-xml". If the PES access point transmits an INFO request including a body (part) with 
AOC information, then ythe Content-Type header field shall include "application/vnd.etsi.aocH-xml", the MIME type 
associated with AOC information (see annex E), and the "sv" or "schemaversion" parameter's value shall be set to the - 
versions of AOC XML Schema that can be used to validate the AOC information XMLdocument. One of the versions 
of the MIME type associated with AOC information (see annex E) - indicated shall correspond with a value of the 
version attribute of the <schema> XML element of an AOC XML Schema (see e.g. annex E). If the "sv" and 
"schemaversion" parameter are absent, the PES access point shall assume that version 1 of the XML Schema for the 
AOC information XML body is supported. If both the "sv" and "schemaversion" parameters are present, then the PES 
access point shall use the "sv" parameter. 

In multiple call leg scenarios like three way conversation or conference calls the PES access point shall process 
charging information received from the PES Application server as described in clause 5.3.3.6: 

• The charging information shall be assumed to be received for each call leg separately from the PES 
Application Server. The PES access point has to combine the AOC information received from the PES 
Application Server. 

• As a network operator option the charging information received may be assumed as a combined representation 
applying to all call legs. The PES access point simply applies the last received charging information to the 
served user. 

5.3.2.7 Supplementary services configuration 

5.3.2.7.1 Analogue lines 

Analogue subscribers can control their supplementary services using service code commands as defined in 

ETS 300 738 [12] included in the user part of the Request-URI of an INVITE message. Further details are provided in 

annex C. 

5.3.2.7.2 ISDN lines 

ISDN subscribers can configure supplementary services using procedures applied at either the Gm reference point or 
the Ut reference point. 

In the case of the Ut reference point, HTTP PUT, HTTP GET or HTTP DELETE requests are used in accordance with 
RFC 4825 [i.l] and the supplementary services application usage specified in TS 124 623 [33]. 

In case of the Gm reference point two procedures are available: 

• Use of service code commands as for analogue subscribers, when ISDN stimulus procedures are used by the 
end user terminal. 

• Use of the MESSAGE method when ISDN functional procedures are used by the end user terminal. 
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The MESSAGE method is used to convey the service related information to the relevant target. The information to 
configure a service is embedded in an XML instance document contained in the MESSAGE request as specified in 
TS 183 036 [40]. 

The P-Asserted-Identity shall be set as specified in clause 5.3.2.4 for an INVITE request. 

The To and From headers shall be set to the public user identity associated to the supplementary service action. This 
public user identity may be built from the line or access identifier (e.g. line-identifier@pes.operator.com) or be a 
directory number obtained by the PES Endpoint through provisioning or at registration in case of line-based 
registration. 

When receiving a MESSAGE request conveying a response to an ISDN supplementary service interrogation procedure 
(see TS 183 036 [40]), the PES access point shall look for the In-Reply-To header field and evaluate its contents to 
identify the initial MESSAGE request to which it is responding. 

5.3.3 PES Application Server 

5.3.3.1 General 

In addition to the procedures specified in the rest of clause 5.3.3, the PES application server shall support the 
procedures specified in TS 124 229 [4] appropriate to an application server. 

5.3.3.2 Basic call procedures 

A PES application server can act either as a proxy server or as a Back to Back User Agent (B2BUA) while processing 
calls. When acting as a B2BUA, the PES application server provides both originating UA and terminating UA functions 
as described in TS 124 229 [4]. As an originating UA that sends outbound INVITE requests, the PES application server 
must appropriately handle responses received from a forking proxy and must appropriately interwork provisional and 
final INVITE responses, as well as other SIP requests, between the originating UA and terminating UA functions 
employed on a single call. 

When handling an outgoing call, the PES application server shall populate the "cpc" URI parameter in the contents of 
the P-Asserted-Identity header as defined in TS 124 229 [4] in each INVITE request, unless the parameter value is 
"ordinary". How the PES application server determines the value of this parameter (UPSF query, local configuration 
data, etc.) is outside the scope of the present document. 

When handling an outgoing call, the PES application server shall override the P-Asserted-Identity with a meaningful 
public user identity (i.e. a Directory number) in each INVITE request if the received P-Asserted-Identity is derived from 
an analogue line or ISDN access identifier or represents a gateway. The PES application server determines this 
meaningful identity from the contents of the P-Asserted-Identity using provisioned mapping table. 

If a P-Access-Network-Info header field containing the location of the calling line is received without the "np" 
parameter and the PES AS has the knowledge that the request comes from a trusted A-VGW, it may decide to insert an 
"np" parameter in it and remove any other P- Access-Network-Info header field that contains the location of this VGW. 

When handling an incoming call, the PES application server shall rewrite the To header field with s URI containing 
either an entity representing the target line/access if group registration was used and directory numbers have not been 
provisioned on the PES access point / PES endpoint, or otherwise the identity received in the Request-URI. In the first 
case, the PES application server determines the identity to be included in the To header field using a provisioned 
mapping table. 

5.3.3.3 Announcement procedures 

The PES application server shall have the capability of requesting announcements during any phase of a session, 
according to the procedures described in TS 124 628 [6]. 

The PES application server shall use the ANNC URL syntax defined in [16] when requesting a PES announcement 
server to play an announcement. 
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A PES application server acting as a B2BUA must appropriately handle received Call-Info, Alert-Info, and Error-Info 
headers that contain requests to play announcements, as defined in TS 124 628 [6]. Depending on the application, this 
may mean relaying the header toward the originating PES endpoint or PES access point, connecting the originating UE 
to an MRF, or ignoring the announcement request and providing some other call processing (such as with a 
simultaneous ringing application that ignores failure announcements from unsuccessful call legs). 

When sending announcements during the call setup phase, the PES application server shall include a P-Early-Media 
header set according to TS 124 628 [6]. 

5.3.3.4 Profile Delivery 

The PES application server shall act as a profile delivery server and manage Profile documents whose structure 
conforms to the XML schema defined in annex A and TS 124 623 [33]. 

The contents of the NOTIFY request shall be as follows: 

• The Event header shall be set to the "ua-profile" event package. 

• The "effective-by" parameter for the event header shall be set to 0. 

• The content type shall be set to "application/simservH-xml". 

In case of implicit subscription the first NOTIFY message is sent when the current profile differs from the network's 
default profile. 

Changes to these documents shall be notified by reporting the "ua-profile" event defined in [15]. How the PES server 
keeps track of changes to these documents is outside the scope of the present document. 

5.3.3.5 Transport of ISUP information 
5.3.3.5.1 General 

Clause 5.3.3.5 describes the general behaviour of the PES application server in the case the PES application server is 
capable of exchanging ISUP information, as defined in ITU-T Recommendation Q.763 [29], carried within Narrowband 
Signalling Syntax (NSS) [31] message bodies with its SIP signalling peers to perform service related signalling that is 
capable of interworking with PSTN services. Clause C. 1 .4 lists examples of services some of which may require the use 
of encapsulated ISUP information. The sending or receiving of ISUP information in NSS message bodies is applicable 
to any of the following roles of the Application Server: 

• PES application server acting as terminating UA or redirect server. 

• PES application server acting as originating UA. 

• PES application server performing 3^^" party call control. 

The procedures defined in the following clauses allow a PES application server to discover whether or not its peer SIP 
signalling entity (i.e. the next UA along the signalling path, which may be a B2BUA, and therefore excluding any 
intermediate proxies) is capable of supporting NSS message bodies within SIP messages, and to successfully support 
the additional exchange of ISUP information needed for those services supported in common by endpoints supporting 
potentially different sets of services. Each IMS PES must assure that NSS message bodies are not forwarded to UEs and 
are not forwarded to untrusted SIP networks according to local policy. Clause 5.3.3.5.2.4 describes the role of the PES 
application server in maintaining NSS security. 

NOTE: Services that require manipulation of the ISUP information within NSS message bodies cannot be 
implemented on application servers acting as a SIP proxy. 

The PES application server shall support parameter translations and defaults defined in TS 129 163 [32] for the ISUP 
information needed for supported services. The PES application server shall also send each piece of ISUP information 
in the appropriate SIP message so as to allow the valid interworking with the corresponding PSTN services according to 
TS 129 163 [32]. The PES application server shall not include in NSS message bodies any ISUP information that is 
already represented by SIP signalling. 

The handling of forked requests with NSS message bodies is for further study. 
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5.3.3.5.2 Sending NSS message bodies to a peer SIP signalling entity 

5.3.3.5.2.1 General 

The PES application server shall send an NSS message body with encapsulated ISUP information in the appropriate SIP 
message to a peer SIP signalling entity according to the clauses 5.3.3.5.2.2 through 5.3.3.5.2.7, when all the following 
conditions are satisfied. 

• The PES application server is capable of performing service related signalling using ISUP information for one 
or more of the services it supports. 

• An event associated with one of the supported services occurs that requires that ISUP information be sent to 
the peer SIP signalling entity. This event may be the receipt of signalling information from another SIP 
interface to the PES application server, or a service event internal to the PES application server. 

• Either the encapsulating message is the initial INVITE request, or the peer SIP signalling entity has previously 
indicated support for NSS message bodies within the associated dialog (see clause 5.3.3.5.2.2). 

• The SIP signalling in the encapsulating message cannot represent the information, and the information is 
different from the default values defined in TS 129 163 [32]. 

NOTE: Information may be duplicated in the NSS and vnd.etsi.pstn XML MIME bodies. 

5.3.3.5.2.2 Determining support for NSS message bodies 

When constructing an initial INVITE request, an originating PES application server that supports any services that 
require encapsulated ISUP information shall include an indication of support for NSS by including an Accept header in 
the initial INVITE request that indicates support for NSS ("application/nss") according to clause 5.3.3.5.2.3. Until the 
originating PES application server receives an indication of support for NSS message bodies from its peer SIP 
signalling entity (by receipt of a SIP message that either includes an Accept header indicating support for NSS or an 
NSS message body), the originating PES application server shall not send any further NSS message bodies within the 
dialog. 

If a terminating PES application server receives an initial INVITE request that does not include an Accept header 
indicating support for NSS, the terminating PES application server shall not send NSS message bodies within the 
dialog. If a terminating PES application server supporting any services that require the signalling of ISUP information 
receives an initial INVITE request that includes an Accept header indicating support for NSS, the terminating PES 
application server shall indicate support of NSS in the first SIP message to its SIP signalling peer. The terminating PES 
application server indicates support of NSS using the Accept header if allowed in the SIP message. Otherwise, the 
terminating PES application server does this by including an NSS message body in the SIP message. In the later case, if 
there is no need to send ISUP information to the SIP signalling peer in the first SIP message, the terminating PES 
application server shall send a generic parameter list (GPL) NSS message with no parameters. 

A terminating PES application server not supporting NSS will follow procedures in clause 5.3.3.5.3.1. 

5.3.3.5.2.3 NSS message bodies 

The PES application server shall format the NSS message body according to ITU-T Recommendation Q. 1980.1 [31]. 
The Content-Type header field associated with the NSS message body shall be included as follows: 

• Content-Type: application/nss. 

The Content-Disposition header field associated with the NSS message body shall be set in one of the following two 
ways (see clause 5.3.3.5.2.7): 

• Content-Disposition: signal; handling = required; or 

• Content-Disposition: signal; handling = optional. 
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5.3.3.5.2.4 ISUP information security 



If network entities in the IMS PES cannot be relied on to provide ISUP information confidentiality and integrity, then 
the PES application server shall not send NSS message bodies or process received NSS message bodies (other than 
ignoring or rejecting any NSS message bodies). 

A PES application server acting as routeing B2BUA shall remove NSS message bodies and indications of NSS support 
(e.g. an NSS entry in the Accept header) from SIP messages being forwarded towards each UE. If a PES application 
server is assigned to remove the NSS message bodies from SIP messages being forwarded to a UE, then the PES 
application server shall be configured within the terminating filter criteria for its UE. 

5.3.3.5.2.5 Determining in winicin message to encapsulate ISUP information 

If a service logic event coincides with one of the SIP basic call control messages, i.e. INVITE request, re-INVITE 
request, BYE request, UPDATE request, or responses to these messages, any required ISUP information shall be 
encapsulated in the corresponding SIP message. 

If a service logic event requiring the sending of ISUP information occurs that does not coincide with one of the SIP 
basic call control messages, the PES application server shall send the ISUP information encapsulated in an INFO 
request or a 183 (Session Progress) response, as described below. 

An originating PES application server cannot send an INFO request until it receives a reliable provisional response or 
final response. 

A terminating PES application server cannot send an INFO request until a reliable provisional response or final 
response has been sent by the PES application server and the response has been acknowledged. If service logic requires 
an NSS message body marked with optional handling (see clause 5.3.3.5.2.7) to be sent before an INFO request can be 
sent, the terminating PES application server may send the NSS message body in a 183 (Session Progress) reliable 
response. If the service logic requires an NSS message body marked with required handling to be sent before an INFO 
request can be sent, the terminating PES application server shall first send a 183 (Session Progress) reliable response 
without an NSS message body and wait for acknowledgment of the response before sending the NSS message body in 
the INFO request. 

5.3.3.5.2.6 Determining the NSS message identifier code 

If the ISUP information included in the NSS message body uniquely identifies the ISUP message needed to interwork 
the ISUP information to an ISUP interface, or if the interworking with ISUP is unambiguously identified by the SIP 
signalling and/or the encapsulated ISUP information, the PES application server shall include the ISUP information in 
an NSS GPL message. Otherwise, the PES application server shall include an explicit ISUP message name in the NSS 
message body. 

5.3.3.5.2.7 Determining the content disposition handling 

5.3.3.5.2.7.1 Content disposition for the initial INVITE request 

A PES application server sending an INVITE request with an NSS message body shall mark it for required handling 
(see clause 5.3.3.5.2.3) if the service logic requires the peer SIP signalling entity to understand the ISUP information. 

Otherwise, the PES application server shall mark the NSS message body in the initial INVITE request for optional 
handUng. 

If the peer SIP signalling entity is unable to process an NSS message body marked for required handling in an initial 
INVITE request, it will reject the INVITE request with a failure response, allowing the originating PES application 
server, or perhaps a proxy on the path, to optionally retry the request to an alternate destination that may be capable of 
handling the NSS message body. 

5.3.3.5.2.7.2 Content disposition for the INFO request 

A PES application server sending an INFO request with an NSS message body shall mark it for required handling if the 
service logic requires the peer SIP signalling entity to understand the ISUP information. 

Otherwise, the PES application server shall mark the NSS message body in the INFO request for optional handling. 
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If the peer SIP signalling entity rejects an NSS message body in an INFO request by returning a failure response, the 
PES application server performs the service procedure that applies when unable to signal ISUP information, if such a 
procedure exists, and continues the call associated with the parent dialog. The PES application server shall release the 
call if the INFO request fails and there is any ISUP information in the INFO request that requires call release if it cannot 
be processed or forwarded. 

5.3.3.5.2.7.3 Content disposition for other SIP messages 

If the previous clauses do not apply, the PES application server shall mark the NSS message body in the SIP message 
for optional handling. 

NOTE: A PES application server sending an NSS message body in any SIP response message will mark it for 
optional handling, since the peer SIP signalling entity cannot reject the message. 

5.3.3.5.3 Receiving an NSS message body from a peer SIP signalling entity 

5.3.3.5.3.1 General 

On receipt of a SIP message containing an NSS message body, a PES application server supporting services that require 
encapsulated ISUP information shall de-encapsulate the ISUP information from the NSS message body, perform the 
processing described in the clause 5.3.3.5.3.2, and trigger the relevant service logic. 

If the PES application server does not receive ISUP information required by the service logic, the service logic defines 
the PES application server behaviour, e.g. by assuming default values defined by the service logic. 

5.3.3.5.3.2 ISUP compatibility procedures 

A PES application server shall reject with a SIP 603 (Decline) response a SIP request that includes an NSS message 
body that is marked for required handling, that includes ISUP information that the PES application server does not 
support, and that either includes no compatibility parameter for the unsupported information, or includes a compatibility 
parameter for the unsupported information that requires release when the parameter is unsupported. Otherwise, the PES 
application server shall ignore any unsupported ISUP information. 

The PES application server may ignore any unsupported ISUP information it receives in an NSS message body marked 
for optional handling or perform any other behaviour determined by the service logic. 

5.3.3.6 Handling of charging information 

When processing originating sessions, the PES application server shall be able to act as a Charging Generation Point 
(CGP) and send the appropriate charging information to the PES access point/endpoint. The PES application server 
shall accept charging information in the format defined in TS 129 658 [42], annex C and may accept charging 
information received as part of an NSS body (see clause 5.3.3.5). 

When processing originating sessions, the PES application server shall be able to insert advice of charge information in 
SIP messages sent to the calling user, using the mechanism described in TS 124 647 [7]. 

When processing originating sessions with multiple call legs to be charged, e.g. in 3-party calls or when using the 
conference service, then the PES Application server shall send related charging information to the PES access 
point/endpoint separately for each call leg. 

As a network operator option the PES application server may send charging information related to the affected call legs 
in a combined representation in a single AOC XML body. 

• When only one dialog is active between the UE and the application server, or after network-based conference 
has been used (as defined in ETSI 24.605) and the UE is left with just one dialog to the conferencing MRF, the 
AS may use this method since separate dialogs no longer exist for each far party. 

• If only one dialog exists between the PES access point/endpoint and the PES application server, the PES 
access point/endpoint is not informed when one of the far parties is released. In order to ensure that charging is 
accurate, the PES application server will have to send an INFO request with an XML body each time a far 
party is added or released. 
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When processing terminating sessions, the PES application server may be able to act as a Charging Determination 
Point (CDP) and send charging information to the calling user using the format defined in TS 129 658 [42], annex C. 

5.3.3.7 Supplementary services configuration 

Three modes of operation may be supported depending on the type access and the operator's policy: 

• Service code commands received in the Request-URI of INVITE message at the ISC reference point. 

• XML documents received in HTTP PUT, HTTP GET or HTTP DELETE requests received at the Ut reference 
point in accordance with RFC 4825 [i.l] and the supplementary services application usage specified in 

TS 124 623 [33]. 

• XML documents received in MESSAGE messages as specified in TS 183 036 [40]. 

When sending a MESSAGE request in response to another MESSAGE request, the PES AS shall set the In-Reply-To 
header field value to the value of the Call-ID header field received in the incoming request. 

5.3.4 PES Announcement Server 

5.3.4.1 General 

In addition to the procedures specified in the rest of clause 5.3.4, the PES announcement server shall support the 
procedures specified in TS 124 229 [4] appropriate to an MRFC. 

5.3.4.2 Announcement procedures 

The PES announcement server shall support the ANNC URL syntax defined in [16] when providing announcements, 
prompt and collect functions, and multi-party conferencing. 

5.3.5 PES Interworking Application 

5.3.5.1 General 

In addition to the procedures specified in the rest of clause 5.3.5, the PES interworking application shall support the 
procedures specified in TS 124 229 [4] and TS 124 628 [6] appropriate to an MGCF. 

The PES interworking application shall support the P-Early-Media header. 

5.3.5.2 Routing procedures 

In case of incoming calls from legacy networks, the PES interworking application determines the next hop in IP routing 
depending on received signalling information, based on configuration data and/or data base look up. The next hop may 
be an I-CSCF, a BGCF or an IBCF. 

Based on the destination and local policy rules, the PES interworking application may include ISUP information in the 
messages sent to the next entity, as described in clause 5.3.5.4. 

5.3.5.3 Handling of charging information 

The PES interworking application shall be able to insert charging information in SIP messages sent to the calling user, 
based on charging information received from the PSTN. The PES interworking application shall use the format defined 
in TS 129 658 [42], annex C. 
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5.3.5.4 Transport of ISUP information 

5.3.5.4.1 General 

The procedures in the clause 5.3.5.4 allow the PES interworking application to discover whether or not its peer SIP 
signalling entity is capable of supporting the encapsulation of ISUP information in Narrowband Signalling Syntax 
(NSS) [31] message bodies within SIP messages, and to successfully support the additional exchange of ISUP 
information needed for those services supported in common by endpoints supporting potentially different sets of 
services. These procedures are based on TS 129 163 [32] with the extended capabilities described in the present 
document. When signalling ISUP information within a SIP dialog, the PES interworking application shall act as either a 
Type A or Type B exchange depending on the role (e.g. gateway between operators, transit) the PES interworking 
application is performing for that particular call and the ability to exchange ISUP information during the call. 
Clause C.1.4 lists examples of services some of them may require the use of encapsulated ISUP information. Each IMS 
PES must assure that ISUP information is not shared with UEs and untrusted SIP networks according to local policy. 
Clause 5.3.5.4.2.4 describes the PES interworking application's role in maintaining NSS security. 

The PES interworking application shall support parameter translations and defaults defined in TS 129 163 [32] for the 
ISUP information needed for supported services. The PES interworking application shall also send each piece of ISUP 
information in the appropriate SIP message so as to allow valid interworking with the corresponding PSTN services 
according to TS 129 163 [32]. The PES interworking application shall not include in NSS message bodies any ISUP 
information that is already represented by SIP signalling. 

The handling of forked requests with NSS message bodies is for further study. 

5.3.5.4.2 Sending ISUP information to a peer SIP signalling entity 

5.3.5.4.2.1 General 

The PES interworking application shall send an NSS message body with encapsulated ISUP information in the 
appropriate SIP message to a peer SIP signalling entity according to the clauses 5.3.5.4.2.2 through 5.3.5.4.2.7, when all 
the following conditions are satisfied. 

• Either the encapsulating message is the initial INVITE request, or the peer SIP signalling entity has previously 
indicated support for NSS message bodies within the associated dialog (see clause 5.3.5.4.2.2). 

• An event occurs requiring signalling to the peer SIP signalling entity. This event may be the receipt of an ISUP 
message from the PSTN, or an event internal to the MGCF. 

• According to local configuration, selected ISUP information shall be encapsulated and sent towards the peer 
SIP signalhng entity. 

• The SIP signalling in the encapsulating message cannot represent the information, and the information is 
different from the default values defined in TS 129 163 [32]. 

NOTE: Information may be duplicated in the NSS and vnd.etsi.pstn XML MIME bodies. 

5.3.5.4.2.2 Determining support for NSS message bodies 

When constructing an initial INVITE request, the O-MGCF supporting NSS message bodies shall include an indication 
of support for NSS by including an Accept header in the initial INVITE request that indicates support for NSS 
("application/nss") according to clause 5.3.5.4.2.3. Until the O-MGCF receives an indication of support for NSS 
message bodies from its peer SIP signalling entity (by receipt of a SIP message that either includes an Accept header 
indicating support for NSS or an NSS message body), the O-MGCF shall not send any further NSS message bodies 
within the dialog. 

If an I-MGCF receives an initial INVITE request that does not include an Accept header indicating support for NSS, the 
I-MGCF shall not send NSS message bodies within the dialog. If an I-MGCF supporting NSS receives an initial 
INVITE request that includes an Accept header indicating support for NSS, the I-MGCF shall indicate support of NSS 
in the first SIP message to its SIP signalling peer. The I-MGCF indicates support of NSS using the Accept header if 
allowed in the SIP message. Otherwise, the I-MGCF does this by including an NSS message body in the SIP message. 
In the later case, if there is no need to send ISUP information to the SIP signalling peer in the first SIP message, the 
I-MGCF shall send a generic parameter list (GPL) NSS message with no parameters. 
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5.3.5.4.2.3 NSS message bodies 



The PES interworking application shall format the NSS message body according to ITU-T Recommendation 

Q. 1980.1 [31]. The Content-Type header field associated with the NSS message body shall be included as follows: 

• Content-Type: application/nss. 

The Content-Disposition header field associated with the NSS message body shall be set in one of the following two 
ways (see clause 5.3.5.4.2.7): 

• Content-Disposition: signal; handling = required; or 

• Content-Disposition: signal; handling = optional. 

5.3.5.4.2.4 ISUP information security 

If network entities in the IMS PES cannot be relied on to provide NSS confidentiality and integrity, then the PES 
interworking application shall not send NSS message bodies or process received NSS message bodies (other than 
ignoring or rejecting any NSS message bodies). 

5.3.5.4.2.5 Determining in winicin SIP message to encapsulate ISUP information 

If an event requiring the sending of ISUP information coincides with one of the SIP basic call control messages, 

i.e. INVITE request, re-INVITE request, BYE request, UPDATE request, or responses to these messages, any required 

ISUP information shall be encapsulated in the corresponding SIP message. 

If an event requiring the sending of ISUP information occurs that does not coincide with one of the SIP basic call 
control messages, the AS shall send the ISUP information encapsulated in an INFO request or a 183 (Session Progress) 
response, as described below. Clause 5.3.5.4.4 describes events unrelated to SIP basic call control messages that may 
require the sending of ISUP information. 

An O-MGCF cannot send an INFO request until it receives a reliable provisional response or final response. 

An I-MGCF cannot send an INFO request until a reliable provisional response or final response has been sent by the 
I-MGCF and the response has been acknowledged. If an event requires an NSS message body marked with optional 
handling (see clause 5.3.5.4.2.7) to be sent before an INFO request can be sent, the I-MGCF may send the NSS message 
body in a 183 (Session Progress) reliable response. If an event requires an NSS message body marked with required 
handling to be sent before an INFO request can be sent, the I-MGCF shall first send a 183 (Session Progress) reliable 
response without an NSS message body and wait for acknowledgment of the response before sending the NSS message 
body in the INFO request. 

5.3.5.4.2.6 Determining the NSS message identifier code 

If the ISUP information included in the NSS message body uniquely identify the ISUP message needed to interwork the 
ISUP information to an ISUP interface, or if the interworking with ISUP is unambiguously identified by the SIP 
signalling and/or the encapsulated ISUP information, the PES interworking application shall include the ISUP 
information in an NSS GPL message. Otherwise, the PES interworking application shall include an explicit ISUP 
message name in the NSS message body. 

5.3.5.4.2.7 Determining the content disposition handling 

5.3.5.4.2.7.1 Content disposition for the initial INVITE request 

An O-MGCF sending an initial INVITE request with an NSS message body shall mark it for required handling (see 
clause 5.3.5.4.2.3) in any of the following cases: 

• The ISUP preference indicator received from the PSTN is set to "ISUP required all the way". 

• The parameter compatibility parameter associated with any ISUP parameter in the NSS message body 
indicates "release call" or "discard message" when pass on is not possible. 

• As a matter of local policy. 
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Otherwise, the O-MGCF shall mark the NSS message body in the initial INVITE request for optional handling. 

If the peer SIP signalling entity is unable to process an NSS message body marked for required handling in an initial 
INVITE request, it will reject the INVITE request with a failure response, allowing the O-MGCF, or perhaps a proxy on 
the path, to optionally retry the request to an alternate destination that may be capable of handling the NSS message 
body. 

5.3.5.4.2.7.2 Content disposition for tine INFO request 

If an event occurs requiring the sending of an NSS message body, the event does not coincide with one of the SIP basic 
call control messages (see table 3 in clause 5.3.5.4.4.1), and any failure procedures are defined when unable to pass on 
ISUP information in the NSS message body to the peer SIP signalling entity, the PES interworking application shall 
mark the NSS for required handling. For example, the "Interactions with other networks" clause of each relevant 
supplementary service specification (see table C.l) specifies the PES interworking application procedures when unable 
to pass on ISUP information. Otherwise, the PES interworking application shall mark the NSS message body for 
optional handling. 

Otherwise, the O-MGCF shall mark the NSS message body in the INFO request for optional handling. 

If the peer SIP signalling entity rejects an NSS message body in an INFO request by returning a failure response, the 
PES interworking application performs the service procedure for failing to pass on the ISUP information, if such a 
procedure exists, and continues the call associated with the parent dialog. The PES interworking application shall 
release the call if the INFO request fails and there is any ISUP information in the INFO request that requires call release 
if it cannot be processed or forwarded. 

5.3.5.4.2.7.3 Content disposition for otiner SIP messages 

A PES interworking application sending an NSS message body in any SIP message other than the INVITE request and 
the INFO request shall mark it for optional handling. 

NOTE: A PES interworking application sending an NSS message body in any SIP response message will mark it 
for optional handling, since the peer SIP signalling entity cannot reject the message. 

5.3.5.4.3 Receiving an NSS message body from a peer SIP signalling entity 

5.3.5.4.3.1 General 

On receipt of a SIP message containing an NSS message body, the PES interworking application supporting NSS shall 
de-encapsulate the ISUP information from the NSS message body, perform the processing described in 
clauses 5.3.5.4.3.2 and 5.3.5.4.3.3, and pass the ISUP information to the relevant ISUP procedures. 

5.3.5.4.3.2 ISUP compatibility procedures (local policy options) 

A PES interworking application shall reject with a SIP 603 (Decline) response a SIP request that includes an NSS 
message body that is marked for required handling, that includes ISUP information that the PES interworking 
application does not support, and that requires release according to ISUP procedures when unsupported. Otherwise, the 
PES interworking application shall ignore any unsupported ISUP information. 

The PES interworking application may ignore any unsupported ISUP information it receives in an NSS message body 
marked for optional handling or perform any other behaviour determined by the ISUP procedures. 

5.3.5.4.3.3 Alignment of SIP signalling and NSS message body contents 

On receipt of a SIP message containing an NSS message body, the PES interworking application shall use the 
encapsulated ISUP information in preference to any value determined by interworking procedures and default values 
defined in TS 129 163 [32]. 



£75/ 



41 



ETSI TS 183 043 V3.4.1 (2011-04) 



5.3.5.4.4 



ISUP messages for special consideration 



5.3.5.4.4.1 



General 



Table 3 lists the PES interworking application behaviour upon receipt of ISUP messages that have no counterparts in 
basic SIP call control messages. 

Table 3: ISUP messages for special consideration 



ISUP message 


Reference 


Subsequent address message 


5.3.5.4.4.6 


Reset circuit 


5.3.5.4.4.2 


Call progress 


5.3.5.4.4.3 (see note 1) 


Circuit group blocking 


5.3.5.4.4.2 


Circuit group blocking acknowledgement 


5.3.5.4.4.2 


Circuit group query (national use) 


5.3.5.4.4.2 


Circuit group query response (national use) 


5.3.5.4.4.2 


Group reset 


5.3.5.4.4.2 


Circuit group reset acknowledgement 


5.3.5.4.4.2 


Confusion 


5.3.5.4.4.2 or 5.3.5.4.4.3 (see note 2) 


Facility reject 


5.3.5.4.4.2 or 5.3.5.4.4.3 (see note 2) 


User-to-user information 


5.3.5.4.4.3 


Forward transfer 


5.3.5.4.4.3 


Subsequent directory number (national use) 


5.3.5.4.4.3 


Suspend 


5.3.5.4.4.3 or 5.3.5.4.4.5 


Resume 


5.3.5.4.4.3 or 5.3.5.4.4.5 


Blocking 


5.3.5.4.4.2 


Blocking acknowledgement 


5.3.5.4.4.2 


Continuity check request 


5.3.5.4.4.2 


Continuity 


5.3.5.4.4.2 


Unblocking 


5.3.5.4.4.2 


Unblocking acknowledgement 


5.3.5.4.4.2 


Unequipped CIC (national use) 


5.3.5.4.4.2 


Circuit group unblocking 


5.3.5.4.4.2 


Circuit group unblocking acknowledgement 


5.3.5.4.4.2 


Charging information (national use) 


5.3.5.4.4.3 


Facility accepted 


5.3.5.4.4.3 


Facility request 


5.3.5.4.4.3 


User part test 


5.3.5.4.4.2 


User part available 


5.3.5.4.4.2 


Facility 


5.3.5.4.4.3 


Network resource management 


5.3.5.4.4.3 


Identification request 


5.3.5.4.4.3 


Identification response 


5.3.5.4.4.3 


Information (national use) 


5.3.5.4.4.3 


Information request (national use) 


5.3.5.4.4.3 


Segmentation 


5.3.5.4.4.4 


Loop back acknowledgment (national use) 


5.3.5.4.4.3 


Loop prevention 


5.3.5.4.4.3 


Overload (national use) 


5.3.5.4.4.2 


Pass-along (national use) 


5.3.5.4.4.3 


Application transport 


5.3.5.4.4.2 or 5.3.5.4.4.3 (see note 2) 


Pre-release information 


5.3.5.4.4.3 


Release complete 


5.3.5.4.4.2 


NOTE 1 : This is the default handling of the ISUP information associated with the Call 

Progress (CPG) message when other clauses in the present document do not 
apply. The ISUP information associated with a CPG message may be 
encapsulated in an 18X response, an UPDATE request, a relNVITE request, or an 
INFO request. 

NOTE 2: The ISUP information in the these messages is either locally terminated or sent 
transparently depending on whether it is destined for the PES interworking 
application or for another exchange. 
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5.3.5.4.4.2 ISUP side procedures only 



ISUP information from these messages is not encapsulated within SIP messages since they relate to procedures that are 
relevant only for the ISUP interface. Typically these messages are related to maintenance of ISUP circuits. If ISUP 
information associated with these ISUP messages is received within an NSS message body, the ISUP information shall 
be discarded. 

5.3.5.4.4.3 Transparent messages 

If the PES interworking application is configured to forward ISUP information meant for end-to-end service 
transparency, the PES interworking application shall send the ISUP information through the SIP network as described 
in clause 5.3.5.4.2.5. 

5.3.5.4.4.4 ISUP segmentation 

ISUP information from the Segmentation message itself is not encapsulated within SIP. Instead the PES interworking 
application will reassemble the original message received from the PSTN with its segmented part and encapsulate any 
relevant information in accordance with other procedures in the present document. 

5.3.5.4.4.5 Receipt of network initiated SUS and RES 

If the I-MGCF is not the controlling exchange for network initiated Suspend procedures and NSS message bodies are 
supported by the peer SIP signalling entity, then the I-MGCF shall forward ISUP information from received SUS and 
RES in NSS message bodies. 

If the I-MGCF is the controlling exchange for network initiated Suspend procedures or is unable to forward SUS 
information to the peer SIP signalling entity, the I-MGCF shall invoke the procedures described in ITU-T 
Recommendation Q.764 [30], clause 2.4.1c on the ISUP interface and shall not forward ISUP information from either 
SUS or RES. 

5.3.5.4.4.6 Subsequent address message 

When receiving overlap signalling on the ISUP interface, the PES interworking application shall include the current 
values of all encapsulated ISUP information in each INVITE request. 

5.3.5.5 Optional SIP/ISUP interworking procedures for PSTN Bridging 

If the PES interworking application can determine that a call is for PSTN bridging (i.e. that the call will end up in an 
ISUP network) then the PES interworking application may, as a network option, use the interworking procedures 
defined in EN 383 001 [20] for Profile C. 

The way the PES interworking application detects that a call is for PSTN bridging is outside the scope of the present 
document (local tables or data base lookups may be used). 

For PSTN bridging, the PES interworking application may route the SIP INVITE request according to the IMS transit 
mechanism, or any other mechanism, based on local policy. 

5.3.6 PES interconnection application 

5.3.6.1 General 

In addition to the procedures specified in the rest of clause 5.3.6, the PES interconnection application shall support the 
procedures specified in TS 124 229 [4] appropriate to an IBCF. 

5.3.6.2 Procedures related to NSS message bodies 

Depending on local policy, the PES interconnection application in an IMS PES supporting NSS, acting as a B2BUA, 
may perform any reasonable combination of the following functions related to an NSS message body within a received 
SIP message, where the message is to be forwarded either into or outside of the IMS PES: 

• removal of an Accept header list entry for NSS ("application/nss"); 
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• removal of an NSS message body marked for optional handling; 

• filtering of NSS message body parameters (e.g. removal of ISUP information associated with a service not 
supported by the network); and 

• rejection of a SIP request that includes an NSS message body marked for required handling by returning a SIP 
415 (Unsupported Media Type) response. 

A PES interconnection application shall only forward NSS message bodies to or from trusted networks supporting NSS. 



Protocol using SIP/SDP for PES 



6.1 Introduction 

This clause identifies the functional entities of the IMS-based PES architecture [3] that play a specific role in the 
provision of PES services with regards to SDP processing in the context of SIP signalling. 

6.2 Functional Entities 

6.2.1 User Equipment (UE) 

Conventional SIP UEs do not exist in PES (see clause 5.2.1). 

For the purpose of the PES, the VGW shall implement the role of a PES endpoint as described in clause 6.3.1. 

6.2.2 Access Gateway Control Function (AGCF) 

For the purpose of the PES, the AGCF shall implement the role of the PES access point as described in clause 6.3.2. 
The AGCF entity encompasses the functionality of a Media Gateway Controller (MGC) and of a SIP User Agent. 

6.2.3 Application Server (AS) 

For the purpose of the PES, the AS shall implement the role of a PES application server, as described in clause 6.3.3. 

6.2.4 Media Resource Function Controller (MRFC) 

For the purpose of the PES, an MRFC shall implement the role of the PES announcement server as described in 
clause 6.3.4. 

6.2.5 Voice over IP gateway (VGW) 

For the purpose of the PES, the VGW shall implement the role of the PES end point as described in clause 6.3.1 . 

The VGW entity encompasses the functionality of a Media Gateway Controller (MGC), Media Gateway (MG) and of 
SIP User Agent. 
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6.3 Roles 

6.3.1 PES Endpoint 

6.3.1.1 General 

In addition to the procedures specified in the rest of clause 6.3.1, the PES endpoint shall support the procedures 
specified in TS 124 229 [4] appropriate to an IMS UE. 

When sending an SDP payload in a SIP message, the PES endpoint shall not include the "i=", "u=", "e=", "p=", "r=", 
and "z=" lines in the SDP, and it shall ignore them when received in the SDP. 

6.3.1.2 Originating Calls 
6.3.1 .2.1 Analogue Access 

For calls originating from an analogue access, the PES endpoint shall build an SDP offer as follows: see below clauses 
concerning the negotiation preparation phase. There are multiple combinations of possibly offered media 
configurations, dependent primarily on locally supported configurations and configuration preferences (see e.g. also 
annex D in [i.5]). 

6.3.1 .2.1 .1 Supported configuration: "VoIP audio" 

• The media description shall contain the G711 A-law codec and may contain other audio codecs as well as 
complementary codecs (e.g. "telephone-event" (see RFC 4733 [17] Comfort Noise (see RFC 3389 [54])) etc.). 

6.3.1 .2.1 .2 Supported configuration: eitlner "V.I 52 VBDolP" or "T.38 FolP" 

• If the PES endpoint is supporting Voiceband data (V.152 VBDoIP emulation service) or Fax over IP (T.38 
FoIP emulation service) the initial session description should contain at least one of the following offers 
dependent on the network configuration: 

preferably (due to its more general nature with respect to PSTN modem calls) an offer for Voiceband 
Data over IP (VBDoIP) according to V.152 [48]; 

in case of knowledge about PSTN G3FE call type: an offer for Fax over IP (FoIP) according to T.38 [49] 
with the additions specified in annex H of the present document. 

6.3.1 .2.1 .3 Supported configuration: botin "V.I 52 VBDoIP" and "T.38 FoIP" 

• If the PES endpoint provides support for both V. 152 and T.38, the PES endpoint shall build an SDP offer as 
follows: 

a) Media configurations for VoIP audio and V.152 VBDoIP: 

■ An "m=" line with the media field set to "audio" and a list of codecs including at least one of the 
G.71 1 static payload types and a dynamic payload type associated to G.71 1 VBD. 

■ An "a=gmpd" line associating the dynamic payload type to G.71 1 VBD. 
bl) Media configuration for T.38 FoIP in case of legacy SDP offer/answer protocol: 

■ If the option for support of revised SDP offer/answer model does not apply: 

An "m=" line signalling support of T.38 according to the profile defined in clause H.3. 

Group the two media descriptions using FID semantics as specified in RFC 3388 [53] 
(note 1). 
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NOTE 1: The application of RFC 3388 [53] allows to establish two media configurations (audio and T.38) in 
parallel, but the usage is conditional (see clause 7.4 in TR 183 072 [i.5]). There are e.g. following 
limitations: 

- T.38 transport variants are not negotiable; 

- other T.38 options (e.g. "T.38 G3" only vs "T.38/V.34 G3") are not negotiable. 

NOTE 2: When the VGW supports V.34-capable T.38 (in the user plane), then it should support the correspondent 
indication and negotiation capability (in the control plane too): such a signalling capability in the (T.38) 
IP domain would be related to T.38 parameter "T38ModemType" in order to discriminate between T.38 
modes "T.38/G3" and "T.38/V.34G3". 

It may be noted that just using the T.38 parameter "T38Fax Version" in order to discriminate between 
T.38 modes "T.38/G3" and "T.38A^.34G3" would be not sufficient (see also clause H.3 in T.38 [49]). 

NOTE 3: T.38 (FoIP-type) specific configurations are e.g. categorized in clause 7.1.2.1 in TR 183 072 [i.5], which 
provides also guidelines concerning indicated and negotiated T.38 parameters. 

An "a=pfmt" attribute set to T.38 if this fax relay is preferred to V.152 VBD. 

NOTE 4: Preferred Configuration (Codec) List (PCL) in SDP offer: This SDP attribute is only required if SDP 

offer is encoded in legacy SDP Offer/ Answer syntax. The indication of preferences is inherent in revised 
SDP Offer/ Answer syntax, related to the numbering of potential configurations (see also clause 7.2.2 in 
TR 183 072 [i.5]). 

b2) Media configuration for T.38 FoIP in case of revised SDP offer/answer protocol: 

■ If the option for support of revised SDP offer/answer model applies: 

An "a=" line explicitly indicating the media capability negotiation according to [50] and [51]. 

At least the following "a=sescap" lines for session configuration allowing: 

- the combination of VoIP (at least for G.711 [23]) and V.152 VBD; 

- the combination of VoIP (at least for G.711 [23]) and Fax over IP as per T.38 [49]. 

NOTE 5: The model of session configurations is required due to the need of two parallel media configurations in 
case of T.38 (see clause D.2.4.2.4 in T.38 [49], or clause 7.4.2.1 in TR 183 072 [i.5]). 

■ If T.38 fax relay is preferred to V.152 VBD then according to the preference schema of revised 
SDP offer/answer model the session capability number associated to T.38 shall be given a lower 
value than the session capability number associated to V.152 VBD. 

■ "a=" lines for the offer of transport and media specific attributes including also T.38 specific 
attributes. 

■ "a=pcfg" lines for potential configurations referenced in "a=sescap" lines. 

■ "a=lcfg" lines if latent configurations apply, which are not intended to be established initially but 
might be already negotiated during the session establishment phase. Same as for potential 
configurations latent configurations are referenced in "a=sescap" lines. 

NOTE 6: The model of latent configuration is required for T.38 support due to the fact that all PSTN modem call 
emulation services starting in voice mode (and not e.g. directly in T.38 mode, see clauses D.2.2.4.3 and 
D.2.4.2.1 in T.38 [49]). 

An example for the coding of an offer indicating preferred support of V. 152 VBD over support of 
T.38 can be found in [48] and [52]. 

6.3.1 .2.1 .4 Supported configuration: "V.I 52 VBDolP" only, no "T.38 FoIP" 

If the PES endpoint provides support for only V.152, the PES endpoint shall build an SDP offer as follows: 
a) Media configurations for VoIP audio and V.152 VBDoIP: 

■ An "m=" line with the media field set to "audio" and a list of codecs including at least one of the 
G.71 1 static payload types and a dynamic payload type associated to G.71 1 VBD. 



• 
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■ An "a=gmpd" line associating the dynamic payload type to G.71 1 VBD. 

■ If the option for support of revised SDP offer/answer model applies then in addition: 

An "a=" line explicitly indicating the media capability negotiation according to [50] and [51]. 

"a=" lines for the offer of transport and media specific attributes. 

"a=pcfg" lines for potential configurations to provide the preferred order of VoIP and 
VBDoIP media configurations. 

6.3.1 .2.1 .5 Supported configuration: "T.38 FolP" only, no "V.I 52 VBDoIP" 

• If the PES endpoint provides support for only T.38, the PES endpoint shall build an SDP offer as follows: 
a) Media configurations for VoIP audio and non-V.152 VBDoIP: 

■ An "m=" line with the media field set to "audio" and a list of codecs including at least one of the 
G.711 static payload types (due to non-V.152 VBDoIP). 

bl) Media configuration for T.38 FoIP in case of legacy SDP offer/answer protocol: 

■ If the option for support of the revised SDP offer/answer model does not apply: 

An "m=" line signalling support of T.38 according to the profile defined in clause H.3. 
Group the two media descriptions using FID semantics as specified in RFC 3388 [53]. 
b2) Media configuration for T.38 FoIP in case of revised SDP offer/answer protocol: 

■ If the option for support of the revised SDP offer/answer model applies 

An "a=" line explicitly indicating the media capability negotiation according to [50] and [51]. 

At least the following "a=sescap" line for session configuration allowing: 

the combination of VoIP (at least for G.711) and Fax over IP as per T.38. 

"a=" lines for the offer of transport and media specific attributes including also T.38 specific 
attributes. 

"a=pcfg" lines for potential configurations referenced in "a=sescap" lines. 

"a=lcfg" lines for potential configurations referenced in "a=sescap" lines. 

6.3.1.2.1.6 Supported configuration: neither "V.I 52 VBDoIP" nor "T.38 FoIP", thus "non-V.152 
VBDoIP" 

• If the PES endpoint provides support for neither V. 152 nor T.38, the PES endpoint shall build an SDP offer as 
follows: 

a) Media configurations for VoIP audio and non-V.152 VBDoIP: 

■ An "m=" line with the media field set to "audio" and a list of codecs including at least one of the 
G.71 1 static payload types (due to non-V.152 VBDoIP). 

6.3.1.2.1.7 Interworking aspects 

If the PES endpoint provides support of V. 152 and/or T.38, any interworking to equipment not supporting V. 152 or 
T.38, shall be covered by backward compatibility procedures using subsequent offer/answer cycles as specified in 
clause 6.3.1.4. 

Annex H gives further details on support of T.38 and V. 152. 
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6.3.1.2.2 ISDN Access 

For calls originating from an ISDN access, the PES endpoint shall build an SDP offer according to TS 183 036 [40]. 

6.3.1.3 Terminating Calls 

6.3.1.3.1 General 

When the PES endpoint sends a SIP Response Code 183 (Session Progress) with SDP payload, it shall only request 
confirmation for the result of the resource reservation at the originating endpoint if there are any remaining unfulfilled 
preconditions. 

6.3.1 .3.2 Analogue Access 

The PES endpoint shall: 

• reject any media descriptions whose media type is different from "m=audio" or "m=image", by setting the 
corresponding port to 0; 



• 



in case of "m=image" for support of Fax over IP in addition the proper subtype stating T.38 shall be verified; 

• check for codecs that match the requested SDP. 

When the PES endpoint generates and sends a SIP Response Code 183 (Session Progress) to an initial SIP INVITE 
request, the PES endpoint shall: 

• set the SDP media description (as SDP answer) indicating the selected audio codec(s) and complimentary 
codecs received in the SDP offer; 

• include a VBD codec as per ITU-Recommendation V.152 if supported by this endpoint and included in the 
received SDP offer. 

If ITU-T Recommendation T.38 [49] is supported by this endpoint and is included in the received SDP, then the SDP 
answer should include a "m=image" line (and T.38 SDP attributes, see also note) indicating support of T.38 as 
described in clause H.3. 

NOTE: T.38 (FoIP-type) specific configurations are e.g. categorized in clause 7.1.2.1 in TR 183 072 [i.5], which 
provides also guidelines concerning indicated and negotiated T.38 parameters. 

6.3.1.3.3 ISDN Access 

Processing of media description for calls terminating on an ISDN access shall conform to TS 183 036 [40]. 

6.3.1 .4 Specific procedures for PSTN modem calls 

The Offer/ Answer exchange previously described results in a Negotiated Codec List (NCL) for the session. For VBD, 
the key point is whether one or both of V. 152 and T.38 is included in the NCL. The order of media configurations in the 
NCL reflects the preferred configurations of both the Offerer and Answerer (e.g. the Offerer did indicate his PCL in the 
sent OCL; see e.g. also annex D in [i.5]). 

If there is support for both V.152 and T.38 in the NCL, then dependent on the configuration preferences, 
e.g. fax/modem may be transmitted via T.38 (fax relay) or V.152 and other non fax/modem traffic may be transmitted 
via V.152 (VBDoIP emulation service). Otherwise, if there is no support for both V.152 and T.38, then fallback 
procedures are necessary - see clause 6.3.1.4.3. 

6.3.1 .4.1 Generation of Preferred Configuration/Codec Lists (for PSTN modem calls) 

The notion of "fax/modem calls" implies multiple media configurations (e.g. for audio, voiceband data or packet relay 
mechanism) indicated and negotiated. TR 183 072 [i.5] provide guidelines for the generation of Preferred 
Configuration/Codec Lists (PCL) for PSTN modem calls. 
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6.3.1 .4.2 Switching between "audio" and "non-audio" modes 

Procedures for switch over from audio mode to fax/modem calls are described in clause H.2 (for voiceband data mode) 
and clause H.3 (for fax relay mode). 

6.3.1.4.3 Fall Back due to lacking support of V. 1 52 and/or T.38 

In the following the basic scenarios for fall back are described: 

• If the NCL contains neither V. 152 nor T.38 then a fall back to pseudo-VBD (G.711, voiceband data merged 
with audio mode) shall apply. 

• If the NCL contains T.38 and not V. 152, then fax data shall be transmitted via T.38 shall happen for PSTN 
G3FE calls, and a fallback to pseudo-VBD for all other non-fax modem call types shall happen. 

NOTE: There might be different fallback procedures with regards to T.38 modes "T.38/G3" and "T.38A^.34G3". 
This related to the explicit signalling of T.38 parameter "T38ModemType". 

If the NCL contains V.152 and not T.38, then, all VBD traffic shall be transmitted via V.152. 

6.3.1.4.4 Non-V. 1 52 VBD Gateway 

A non-V.152 VBD gateway lacks support of V.152 SDP information elements, i.e. lacking support of RTP PT 
assignments of dynamic range for "VBD codec". However, such gateways may provide some basic support VBD calls 
if the following capabilities would be implemented: 

the ability to detect VBD stimuli; 

the control of echo cancellers (EC) as per ITU-T Recommendation G.168 [55] (taking into account the 
operational relation of ECs and VBD according clause 6.2 of V.152); 

the disabling Voice Activity Detection and Comfort Noise Generation if any of these had been activated; 

ensuring end-to-end constant latency; 

ensuring that voice packet loss concealment techniques and algorithms that may be employed are suitable for 
modem and facsimile modulations; and 

the disabling any DC removal filters that may be integral with the speech encoder used. 

Non-V.152 VBD Gateways reuse the Audio G.711 media formats "PCMU" and "PCMA" with its "RTP/AVP" profile 
(RFC 3551 [i.7]) specific static RTP payload value assignments for VBD purpose ("a merged audio/VBD mode"). Each 
end transitions independently to non-V.152 VBD mode based only on local VBD stimuli detection. 

The non-V.152 VBD Gateway uses only static payload types (PCMU) or 8 (PCMA) according to "RTP/AVP" profile 
(RFC 3551 [i.7]) for VBD. 

The following rules shall be applied in order select PCMA or PCMU for the VBD codec at start of call: 

• If the negotiated codec list (NCL) includes a single PCM format, use the correspondent static PCM RTP 
payload type for the VBD codec. If the NCL includes both PMCU and PCMA, the highest priority G.71 1 
codec is used for VBD. 

• If the NCL does not include G.71 1, upon VBD stimuh detection the VGW should send a SIP Re-INVITE with 
a new SDP OFFER containing only the supported G.71 1 static payload type(s). Upon successful negotiation of 
a G.71 1 static payload type in the SDP ANSWER, that same payload type shall be re-used as the VBD codec. 
Note that if G.71 1 is not contained in the SDP ANSWER, then the VGW shall initiate appropriate exception 
handling (e.g. release the call). Such exception handling is out of scope of the present document. 
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6.3.2 PES Access Point 

6.3.2.1 General 

In addition to the procedures specified in the rest of clause 6.3.2, the PES access point shall support the procedures 
specified in TS 124 229 [4] appropriate to an AGCF. 

When sending an SDP, the PES access point shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" lines in the 
SDP, and it shall ignore them when received in the SDP. 

6.3.2.2 Originating calls 

The PES access point shall follow the procedures described in clause 6.3.1.2 Originating Calls for the PES endpoint. 

6.3.2.3 Terminating calls 

6.3.2.3.1 General 

When the PES access point sends a 183 (Session Progress) response with SDP payload, it shall only request 
confirmation for the result of the resource reservation at the originating endpoint if there are any remaining unfulfilled 
preconditions. 

6.3.2.3.2 Analogue Access 

The PES access point shall follow the procedures described in clause 6.3.1.3.2 Analogue Access for the PES endpoint. 

6.3.2.3.3 ISDN Access 

Processing of media description for calls terminating on an ISDN access shall conform to TS 183 036 [40]. 

6.3.2.4 Void 

6.3.2.5 Specific Procedures for Fax/Modem Calls 

The procedures between the AGCF and AGW are described in clause 6.2 of TS 183 002 [5]. 

6.3.3 PES Application Server 
6.3.3.1 General 

In addition to the procedures specified in the rest of clause 6.3.3, the PES application server shall support the 
procedures specified in TS 124 229 [4] appropriate to an application server. 

When acting as a B2BUA, the PES application server must appropriately handle SDP received in responses received 
from a forking Proxy and must appropriately interwork SDP received in provisional and final INVITE responses, as 
well as other SIP requests, between the originating UA and terminating UA functions employed on a single call. 

6.3.4 PES Announcement Server 
6.3.4.1 General 

In addition to the procedures specified in clause 6.3.4, the PES announcement server shall support the procedures 
specified in TS 124 229 [4] appropriate to an MRFC. 
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6.3.5 SDP support for PSTN modem calls 



Clauses 6.3.1 and 6.3.2 define SDP capabilities, required for the emulation of PSTN modem calls by the IMS domain. 
These SDP capabilities are primarily subject of 3GPP specifications, resulting in a dependency of the present document 
to some 3GPP specifications. 

Status -end of 20 10: 

Existing 3GPP Release 9 specifications for TS 124 229 [4] and TS 129 163 [32] still lacking support of SDP 
attributes for T.38 and V.152, which prevents the indication and negotiation of correspondent media 
configurations. 

NOTE: Lacking support of SDP attributes for T.38 and V.152 by 3GPP specifications TS 124 229 [4] and 

TS 129 163 [32] allows just a limited support of emulation services for PSTN modem calls as defined in 
clauses 6.3.1 and 6.3.2 in the present document (see also [i.5]). The TISPAN R3 defined solution does in 
this respect not provide any added value in comparison to pre-R3 releases. 

Annex I provides an indication on possible impact on IMS-based PES network deployments. 



Protocol using H.248 for PES 



7.1 Introduction 

This clause identifies the functional entities of the IMS -based PES architecture [3] that play a specific role in the 
provision of PES services with regards to H.248 processing. 

7.2 Functional Entities 

7.2.1 Access Gateway Control Function (AGCF) 

For the purpose of the PES, the AGCF shall implement the role of the PES access point as described in clause 7.3.1. 

The AGCF entity encompasses the functionality of an H.248 Media Gateway Controller (MGC) and of a SIP User 
Agent. Within the AGCF, the MGC and SIP UA components are coordinated by a Feature Manager entity whose 
logical behaviour is described in annex B. 

7.2.2 Media Gateway Function (MGF) 

For the purpose of the PES, the MGF shall implement the role of the PES media gateway as described in clause 7.3.2. 

7.3 Roles 

7.3.1 PES Access Point 

7.3.1.1 General 

In addition to the procedures specified in the rest of clause 7.3.1, the PES access point shall support the procedures 
specified in TS 183 002 [5] appropriate to an MGC. 

7.3.1.2 Registration 

Registration is supported using the H.248 Service Change procedure. Registration can be performed on a group basis or 
on a per line/access basis. This event is passed to the Feature Manager. 

NOTE: A group may consist of all lines connected to a PES media gateway or to a subset of the media gateway. 
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When the group basis registration mechanism applies, on receipt of a ServiceChange command with "Root" 
TerminationID from the PES media gateway reporting the MGW state changing event and after processing the event 
according to normal service change procedures has finished, the MGC in the PES access point shall send a 
Service-Change primitive to inform the Feature Manager if the ServiceChangeMethod is set to "Restart" with 
ServiceChangeReasons 901 ("Cold Boot") or 902 ("Warm Boot") or "Forced" or "Graceful". 

Receipt of a ServiceChange command from the PES media gateway reporting a Terminations state changing event shall 
not cause the MGC in the PES access point to notify the Feature Manager. 

When the per line basis registration mechanism applies, on receipt of a ServiceChange command from the PES media 
gateway, and after processing the event according to normal service change procedures has finished, the MGC in the 
PES access point shall send a Service-Change primitive to inform the Feature Manager if the ServiceChangeMethod is 
set to "Restart" with ServiceChangeReasons 900 ("Service Restored") or 902 ("Warm Boot") or "Forced" or "Graceful". 

When the MGC in the PES access point detects that the PES media gateway lost communication with the MGC in the 
PES access point, but it was subsequently restored, since MGW state may have changed, the MGC in the PES access 
point may use the H.248 Audit mechanism to resynchronize its state with the PES media gateways. If the MGC in the 
PES access point detects that the audited state of the specified Terminations is different from the recorded state, the 
MGC in the PES access point shall use a Service-Change primitive with proper parameters to inform the Feature 
Manager about the event. 

When the MGC in the PES access point detects that the PES media gateway lost the communication with the PES 
media gateway, the MGC in the PES access point shall use Service-Change primitive with proper parameters to inform 
the Feature Manager about this event. 

7.3.1 .3 Basic Session control procedures for analogue lines 

7.3.1 .3.1 Originating side procedures 

7.3.1.3.1.1 Call Initiation 

Step (IDLE) 

On receipt of a Notify command from the PES media gateway reporting the off-hook (al/of) event the PES access point 
shall: 

• Derive the user identity associated with the termination reporting the event. 

• Report the occurrence of the off-hook event to the Feature Manager using a Session-Attempt primitive. 

• If the subscriber profile (see annex A) contains a no-dialling-behaviour = immediateCallSetup indication, 

request the PES media gateway to create an H.248 context with the caller's analogue termination and an 
ephemeral termination; 

send a Setup Request primitive to the Feature Manager without digits, SDP information shall be set 
according to the information received in the Reply to the H.248 Add command used to create the 
ephemeral termination; 

request the PES media gateway to detect and report al/on event, and 

proceed to step 2, waiting for either al/on or an event from the Feature Manager. 

• Otherwise interact with the Feature Manager to determine which dial tone pattern shall be applied (see 
clause 5.3.2.2). 

• Request the PES media gateway to apply the signal that correspond to the selected dial tone (cg/dt or srvt/mwt 
or xcg/spec) according to the value of the dial-tone-pattern element of the Dial Tone Management document 
described in annex A. 

• Request the PES media gateway to detect and report al/on event. 
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NOTE 1 : The PES media gateway terminations may also be preconfigured by the PES access point, using signals 
and events descriptors embedded in the al/of event descriptor, in such a way that upon detection of the 
off-hook event, the dial tone is automatically delivered and the digit collection is automatically started. 
The PES access point replaces the event descriptors in case the dial tone is modified. 

• Request the PES media gateway to detect and report the xdd/xce event, according to the digit map in force and 
proceed with step 1 . 

Step 1 (Outgoing Seizure -prior sending of digits) 

On receipt of the al/on event, the PES access point shall send a Session-Release-Request primitive to the Feature 
Manager and complete call clearing procedures as specified in clause 7.3.1.3.1.2. 

On receipt of the notification of the xdd/xce event, the PES access point shall: 

• If the received digits do not correspond to a valid number but receipt of additional digits may lead to a valid 
number, request the PES media gateway to detect and report the following events: 

the xdd/xce event, according to a subsequent digit map; 

the al/on event. 

This step may be repeated several times, until a valid number has been collected or the user has abandoned the call 
attempt by going back on-hook. 

• If the received digits do not correspond to a valid number and receipt of additional digits cannot lead to a valid 
number: 

initiate call clearing. 

• If the received digits correspond to a complete number, the PES access point shall: 

request the PES media gateway to create an H.248 context with the caller's analogue termination and an 
ephemeral termination; 

send a Setup-Request primitive to the Feature Manager. SDP information shall be set according to the 
information received in the Reply to the Add command; 

request the PES media gateway to detect and report the following events: 

1) the al/fl event; 

2) the al/on event. 

wait for either of these events and for events from the Feature Manager. Proceed to step 2 on the 
occurrence of any of these events. 

• If no digits are received with the xdd/xce event, the PES access point shall initiate call clearing during off- 
hook (clause 7.3.1.3.1.3) unless the subscriber profile (see annex A) contains a no-dialling-behaviour = 
deferredCallSetup indication. In the latter case the PES access point shall: 

request the PES media gateway to create an H.248 context with the caller's analogue termination and an 
ephemeral termination; 

request the PES media gateway to detect and report the al/on event; 

send a Setup Request primitive to the Feature Manager without digits, SDP information shall be set 
according to the information received in the Reply to the H.248 Add command used to create the 
ephemeral termination; 

wait for either the al/on event or an event from the Feature Manager. Proceed to step 2 on the occurrence 
of any of these events. 

Step 2 (Outgoing Seizure - after sending of digits) 

On receipt of the notification of the al/on event, the PES access point shall send a Session-Release-Request primitive 
to the Feature Manager and complete call clearing procedures as per clause 7.3.1.3.1.2. 
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On receipt of the notification of the al/fl event, the PES access point shall notify its Feature Manager using a Feature 
Request primitive. 

On receipt of a Session Progress primitive from the Feature Manager without alerting indication, the PES access point 
shall: 

• If the primitive contains an early media indication resulting from the presence of a P-Early-Media header field 
in the associated SIP response, request the PES media gateway to modify the ephemeral termination properties 
accordingly so that the calling party can perceive in band information. 

NOTE 2: The termination mode may be set to send-receive or receive-only depending on the network operator's 
policy. 

• If the primitive does not contain an early media indication, ignore the event. 

• Remain in the same state. 

On receipt of a Session Progress primitive from the Feature Manager indicating alerting, the PES access point shall: 

• If the primitive contains an early media indication resulting from the presence of a P-Early-Media header field 
in the associated SIP response, request the PES media gateway to modify the ephemeral termination properties 
accordingly so that the calling party can perceive in band information. 

NOTE 3: The termination mode may be set to send-receive or receive-only depending on the network operator's 
policy. 

• If the primitive does not contain an early media indication, request the PES media gateway to apply the cg/rt 
signal to the physical termination. 

• Proceed with step 3. 

On receipt of a Setup-Response primitive reporting a busy condition, the PES access point shall: 

• Initiate call clearing during off -hook procedure (clause 7.3.1.3.1.3). 

NOTE 4: In this case the PES media gateway to apply the cg/bt signal to the physical termination at the start of the 
call clearing. 

On receipt of an internal Setup-Response primitive reporting that no response has been received from the destination, 
the PES access point shall: 

• Initiate Call Clearing during off-hook procedure (clause 7.3.1 .3.1 .3). 

• If required by local policy, request the PES media gateway to apply a signal (e.g. cg/ct) to the physical 
termination depending on the type of failure. 

On receipt of an internal Setup-Response primitive reporting any other failure condition, the PES access point shall: 

• Initiate Call Clearing during off-hook procedure (clause 9.3.1 .3.1 .3). 

On receipt of a Setup-Response primitive reporting answer from the destination, the PES access point shall: 

• Request the PES media gateway to set the mode of the termination to send-receive. 

• Modify the ephemeral termination's remote descriptor properties in accordance with SDP information received 
from the remote side, if any. 

• As an operator's option request the PES media gateway to apply the xal/las signal. 

• Proceed with step 4. 

Step 3 (Outgoing Seizure -provisional response received) 

On receipt of the al/on event, the PES access point shall send a Session-Release-Request primitive to the Feature 
Manager and complete call clearing procedures as specified in clause 7.3.1.3.1.2. 
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On receipt of the notification of the al/fl event, the PES access point shall notify the feature manager using a Feature 
Request primitive. 

On receipt of a Setup-Response primitive reporting that no response has been received from the destination or any 
other failure, the PES access point shall: 

• Request the PES media gateway to stop the ring back (cg/rt) signal if application of this signal had been 
requested before. 

• Send a Session-Release-Request primitive to the Feature Manager and complete Call Clearing procedures as 
specified in clause 7.3.1.3.2.1. 

On receipt of a Setup-Response primitive reporting answer from the destination, the PES access point shall 

• Request the PES media gateway to set the mode of the ephemeral termination to send-receive if not performed 
previously. 

• Modify the ephemeral termination's remote descriptor properties in accordance with SDP information received 
from the remote side, if any. 

• As an operator's option request the PES media gateway to apply the xal/las signal. 

• Proceed with step 4. 

Step 4 (Outgoing Session established) 

On receipt of a Session-Release-Request primitive from the Feature Manager, the PES access point shall initiate the 
call clearing during off -hook procedure (clause 9.3.1.3.1.3). 

On receipt of a Charging-Indication primitive, depending on operator policy the PES access point shall either: 

• Generate metering pulses by rules described in clause C.2 and request the PES media gateway to apply one of 
the signals for sending metering pulses (amet/em or amet/mpb or amet/phsm) defined in ITU-T 
Recommendation H.248.26 [14]. 

• Build an Advice Of Charge message (see ES 200 659-3 [10]) by rules described in annex D and request the 
media gateway to transmit this message, using the Generic Data Signalling (data) signal of the Analog Display 
Signalling (andisp) package defined in ITU-T Recommendation H.248.23 [13]. 

On receipt of a Session-Update primitive, the PES access point shall modify the ephemeral termination properties 
accordingly. 

On receipt of the al/on event, the PES access point shall send a Session-Release-Request primitive to the Feature 
Manager and complete call clearing procedures as specified in clause 7.3.1.3.1.2. 

On receipt of the notification of the al/fl event, the PES access point shall notify the feature manager using a Feature 
Request primitive. 

7.3.1 .3.1 .2 Call Clearing upon On-Hook 

On receipt of a Session-Release-Confirm primitive from the Feature Manager the PES access point shall: 

• As a network option request the PES media gateway to apply the xal/nd signal. 

• Request the PES media gateway to subtract the ephemeral termination from the current context. 

• Request the PES media gateway to move the termination back to the Null context (i.e. subtract command). 

NOTE: The PES media gateway applies Normal Polarity (i.e. if a Reversed Polarity has been applied to the line at 
start of call, it is removed upon termination going back to Null context). 

• Proceed with step 0. 

On receipt of a Session-Release-Suspend primitive from the Feature Manager the PES access point shall request the 
MGW to monitor the al/of event. If the al/of event is detected, the PES access point shall send a Session-Resume 
primitive to the Feature Manager and re-enter Step 4 of the previous phase. 
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7.3.1 .3.1 .3 Call Clearing during Off-Hook 

Upon entering this step, the PES access point shall: 

Request the PES media gateway to generate an appropriate announcement or tone on the subscriber line. 

As a network option, upon end of announcement or tone, request the PES media gateway to apply the xal/nd 
signal. 

Request the PES media gateway to subtract the ephemeral termination from the current context. 

On receipt of the al/on event, the PES access point shall: 

Request the PES media gateway to move the termination back to the Null context (i.e. subtract command). 

if a Session Release-Request primitive has been previously received from the Feature Manager, send a 
Session-Release-Confirm to the Feature Manager. 

Proceed with step 0. 

If the calling party is still off-hook upon end of announcement or tone, the PES access point shall, after expiry of a 
network configured timer, request the PES media gateway to apply the off -hook warning tone (xcg/roh) to the physical 
termination. 

7.3.1 .3.2 Terminating side procedures 

7.3.1.3.2.1 Call Initiation 

Step (Idle) 

On receipt of a Setup-Request primitive from the internal SIP UA (via the Feature Manager), the PES access point 
shall: 

• Check that the required bearer service is compatible with analogue lines, otherwise return a Setup-Response to 
the Feature Manager, with a reject indication. 

• Determine which physical termination(s) are associated with the target public user identity. 

• If no termination is associated with the called party, the PES access point shall send a Setup-Response 
primitive with a failure indication to the internal SIP UA via the Feature Manager. If a single termination is 
associated to the target public user identity, select this termination otherwise if multiple terminations are 
associated to the target public user identity, select one termination. 

• Check the administrative status of the selected termination. If the termination is out of service, the PES access 
point shall send a setup-response primitive with a failure indication to the internal SIP UA via the Feature 
Manager or select another termination if multiple terminations are associated to the called number. If all 
terminations are out of service, the PES access point shall send a Setup Response primitive with a failure 
indication to the internal SIP UA via the Feature Manager. 

• Check whether the selected termination is already engaged in a call. 

NOTE 1 : As an operator's option, an AuditValue command may be sent to the Media Gateway to verify the status 
of the termination. 

NOTE 2: The algorithm for selecting a termination in case multiple terminations are associated to the same public 
user identity (fixed priority, round-robin, etc.) is outside the scope of the present document. 

NOTE 3: It is expected that only one termination will be associated to a public user identity when the tight-coupling 
mode is used. 

If the selected termination is not engaged in a call, the PES access point shall: 

• Create an H.248 context with an ephemeral termination, based on the session description information received 
in the Setup-Request. 
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• Add the physical termination representing the called party's line to the newly created context. 

• Request the PES media gateway to apply ringing to the physical termination using the andisp/dwa signal. The 
Display Data Block parameter of the andisp/dwa signal shall be set as specified in annex D. As directed by the 
AS (with a SIP Alert-Info header in the INVITE request), the PES access point may direct the PES media 
gateway to apply a distinctive ringing tone by setting the pattern parameter to the appropriate value. 

NOTE 4: The alert/ring signal may be used in place of the andisp/dwa signal in networks where presentation of call 
information to the called party is not supported. 

• Send a Session-Progress (Alerting) primitive to the Feature Manager. 

• Start a no-answer timer. 

• Request the PES media gateway to detect the off-hook event (al/of). 

• Proceed to step 1 . 

If the selected termination is already engaged in a call and multiple terminations are associated to the same called 
number, select an alternative termination and repeat the above procedures. 

If the selected termination is already engaged in a call and there is no alternative "in-service" termination that can be 
selected, the PES access point shall either: 

• Send a Setup-Response (busy) primitive to the Feature Manager if an explicit indication that the Call Waiting 
service is not provisioned to the user has been received as part of the profile delivery procedure or as a 
network option if the incoming Setup-Request does not contain a MIME body indicating that the terminating 
user is subscribed to the Call Waiting service as defined in TS 124 615 [44]; or 

• Initiate a call waiting procedure: 

Create an H.248 context with an ephemeral termination, based on the session description information 
received in the Setup-Request. 

Request the PES media gateway to apply the call waiting tone to the physical termination using the 
andisp/dwa signal. The Display Data Block parameter of the andisp/dwa signal shall be set as specified 
in annex D. As directed by the AS (with a SIP Alert-Info header in the INVITE request), the PES access 
point may direct the PES media gateway to apply a distinctive call waiting tone by setting the pattern 
parameter to the appropriate value. 

NOTE 5: The cg/cw signal may be used in place of the andisp/dwa signal in networks where presentation of call 
information to the called party is not supported. 

Send a Session-Progress (Alerting) primitive to the Feature Manager, including 
'urn:alert:service:call-waiting' to be inserted in the Alert-Info header field of the corresponding SIP 

message. 

Start a call-waiting timer. 

Proceed to step 1 . 

If a Session-Release-Request primitive is received from the feature manager (resulting from receipt of a CANCEL 
request by the internal UA), the PES access point shall: 

• Request the PES media gateway to subtract the ephemeral termination. 

• Request the PES media gateway to move the physical termination back to the Null context. 

• Send a Session-Release-Confirm primitive to the Feature Manager. 
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Step 1 (Incoming Seizure) 

If an off -hook (al/of) event is notified, the PES access point shall: 

• Request the PES media gateway to detect the following events: 

the al/fl event; 
the al/on event. 

• Report the occurrence of the off-hook event to the Feature Manager using a Setup-Response (answer) 
primitive. 

• Proceed to step 2. 

If the no-answer timer (line free) or call-waiting-timer (line busy) expires, the PES access point shall: 

• send a Setup-Response (no answer) primitive to the internal UA via the Feature Manager. 

• Request the PES media gateway to stop the signal sent to the called party (ringing or call waiting signal). 

• Request the PES media gateway to stop the signal sent to the calling party (ring back tone or the 
announcement). 

• Move the physical termination representing the called party's line back to the NULL context, unless this 
termination is already engaged in another call. 

• Send a Session-Release-Request primitive to the Feature Manager and complete call clearing procedures as 
specified in clause 7.3.1.3.2.2. 

Step 2 (Incoming Session established) 

If the al/fl event is received from the PES media gateway, notify the Feature Manager using a Feature Request 

primitive. 

On receipt of a Session-Update primitive, the PES access point shall modify the ephemeral termination properties 
accordingly. 

If the al/on event is received from the PES media gateway, the PES access point shall send a Session-Release-Request 
primitive to the Feature Manager and complete call clearing procedures as per clause 7.3.1.3.2.2. 

If a Session-Release-Request primitive is received via the Feature Manager from the internal UA, the PES access point 
shall initiate call clearing during off-hook procedure (clause 7.3.1.3.2.3). 

7.3.1 .3.2.2 Call Clearing upon On-Hook 

On receipt of a Session-Release-Confirm primitive from the Feature Manager the PES access point shall: 

• Request the PES media gateway to subtract the ephemeral termination. 

• Request the PES media gateway to move the physical termination back to the Null context. 

• Proceed with step 0. 

On receipt of a Session-Release-Suspend primitive from the Feature Manager the PES access point shall request the 
MGW to monitor the al/of event. If the al/of event is detected, the PES access point shall send a Session-Resume 
primitive to the Feature Manager and re-enter Step 2 of the previous phase. 

7.3.1 .3.2.3 Call Clearing during Off-Hook 
Upon entering this step, the PES Access Point shall: 

• Request the PES media gateway to subtract the ephemeral termination. 

• Request the PES media gateway to apply an appropriate announcement or tone (e.g. busy tone, congestion 
tone etc.) to the physical termination. 
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On receipt of the al/on event, the PES Access point shall: 

• Request the PES media gateway to move the physical termination back to the Null context. 

• Report the occurrence of the on-hook event to the Feature Manager using a Session-Release-Confirm 
primitive if a Session-Release-Request had been received. 

• Proceed with step 0. 

If the line is still off-hook at the end of the announcement/tone, request the PES media gateway to apply the off-hook 
warning tone (xcg/roh) to the physical termination after expiry of a network configured timer. 

7.3.1 .4 Procedures for fax/modems calls over analogue access 

In order to be able to properly handle fax and modem calls, the PES access point requests the media gateway to monitor 
the ctyp/dtone event. 

On receipt of a notification of the ctyp/dtone event, the AGCF notifies the Feature Manager if the recognized tone 
corresponds to a supported fax/modem. Otherwise, the event is discarded. 

7.3.1 .5 Message Waiting Indication for analogue access 

On receipt of a Service Notification primitive reporting the "message-summary" event, the PES access point shall 
request the media gateway to apply the Generic Data Signalling signal of the andisp package defined in ITU-T 
Recommendation H.248.23 [13]. The value of the TAS parameter is provisioned in the media gateway or in the PES 
access point, per media gateway or per line. Annex D specifies the populating rules for the Data Block parameter of the 
Generic Data Signalling signal. 

7.3.1 .6 Procedures for ISDN access 

FFS. 

7.3.2 PES Media Gateway 

The PES media gateway shall support the H.248 procedures specified in TS 183 002 [5] appropriate to an MG. 



8 Protocol using DSS1 for PES 

8.1 Introduction 

This clause identifies the functional entities of the IMS-based PES architecture [3] that play a specific role in the 
provision of PES services with regards to DSS.l processing. 

8.2 Functional Entities 

8.2.1 User Equipment (UE) 

Conventional SIP UEs do not exist in PES (see clause 5.2.1). 

For the purpose of the PES, the VGW shall implement the role of a PES endpoint as described in clause 8.3.1. 

8.2.2 Access Gateway Control Function (AGCF) 

For the purpose of the PES, the AGCF shall implement the role of the PES access point as described in clause 8.3.2. 
The AGCF entity encompasses the functionality of a Media Gateway Controller (MGC) and of a SIP User Agent. 



£75/ 



59 ETSI TS 1 83 043 V3.4.1 (201 1 -04) 

8.2.3 Signalling Gateway Function (SGF) 

For the purpose of the PES, the SGF shall implement the role of the PES signalling gateway as described in 
clause 8.3.3. 

NOTE: For the purpose of relaying call control signalling (SAPI=0), the SGF is co-located with an MGF. As a 
network option, an SGF may also be co-located with the VGW for relaying p-type and f-type frames 
(SAPI=16 or SAPI between 32 and 62). 

8.2.4 Voice over IP gateway (VGW) 

For the purpose of the PES, the VGW shall implement the role of the PES endpoint as described in clause 8.3.1. 

The VGW entity encompasses the functionality of a Media Gateway Controller (MGC), Media Gateway (MG) and a 
SIP User Agent. 

8.3 Roles 

8.3.1 PES Endpoint 

The PES Endpoint shall support the DSSl protocol according to EN 300 403-1 [41]. 

8.3.2 PES Access Point 

The PES Access point shall support the DSSl protocol according to EN 300 403-1 [41] and one or more backhaul 
procedures described in TS 183 002 [5] for relaying ISDN D-channel information, depending on the type of ISDN 
access supported. 

8.3.3 PES Signalling Gateway 

The PES signalling gateway shall support one or more backhaul procedures described in TS 183 002 [5] for relaying 
ISDN D-channel information, depending on the type of ISDN services supported. 



9 Protocol using analog signalling for PES 

9.1 Introduction 

This clause identifies the functional entities of the IMS-based PES architecture [3] that play a specific role in the 
provision of PES services with regards to analog signalling processing. 

9.2 Functional Entities 

9.2.1 User Equipment (UE) 

Conventional SIP UEs do not exist in PES (see clause 5.2.1). 

9.2.2 Access Gateway Control Function (AGGF) 

For the purpose of the PES, the AGCF shall implement the role of the PES access point as described in clause 9.3.2. 
The AGCF entity encompasses the functionality of a Media Gateway Controller (MGC) and of a SIP User Agent. 
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9.2.3 Voice over IP gateway (VGW) 

For the purpose of the PES, the VGW shall implement the role of the PES endpoint as described in clause 9.3. 1 . 

The VGW entity encompasses the functionality of a Media Gateway Controller (MGC), Media Gateway (MG) and a 
SIP User Agent. 

9.2.4 Media Gateway Function (MGF) 

For the purpose of the PES, the MGF shall implement the role of the PES media gateway as described in clause 9.3.3. 

9.3 Roles 

9.3.1 PES Endpoint 

9.3.1.1 General 

The external behaviour of a PES Endpoint is equivalent to the combined behaviour of a PES Access Point and a PES 
Media Gateway. 

9.3.1.2 Registration 

Registration can be performed on a group basis or on a per line/access basis. This event is passed to the Feature 
Manager. 

NOTE: A group may consist of all lines connected to a PES Endpoint or to a subset. 

When the group basis registration mechanism applies, upon restart or shutdown of the system the PES endpoint shall 
send a Service-Change primitive to inform the Feature Manager. Change of the status of a physical line within one 
group shall not cause the PES endpoint to notify the Feature Manager. 

When the per line basis registration mechanism applies, the PES endpoint shall send a Service-Change primitive to 
inform the Feature Manager when a physical line is taken out of service or is restored or is added to the system. 

9.3.1 .3 Basic Session control procedures for analogue lines 
9.3.1 .3.1 Originating side procedures 

9.3.1.3.1.1 Gall Initiation 

Step (Idle) 

Upon detection of the off-hook event the PES endpoint shall: 

• Derive the user identity associated with the analogue line where the event was detected. 

• Report the occurrence of the off-hook event to the Feature Manager using a Session-Attempt primitive. 

• If the subscriber profile (see annex A) contains a no-dialling-behaviour = immediateCallSetup indication, 

send an empty Setup Request primitive to the Feature Manager, 

start monitoring the on-hook event, and 

proceed to step 2, waiting for either on-hook or an event from the Feature Manager. 

• Otherwise interact with the Feature Manager to determine which dial tone pattern shall be applied (see 
clause 5.3.2.2). 
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Apply on the subscriber line the signal that correspond to the selected dial tone (cg/dt or srvt/mwt or xcg/spec) 
according to the value of the dial-tone-pattern element of the Dial Tone Management document described in 
annex A. 



• 



• 



Start monitoring the on-hook event. 

Start collecting digits on the subscriber line, according to the digit map in force and proceed with step 1 . 

Step 1( Outgoing Seizure - prior sending of digits) 

On receipt of the on-hook event, the PES endpoint shall send a Session-Release-Request primitive to the Feature 
Manager and complete call clearing procedures as specified in clause 9.3.1.3.1.2. 

On receipt of a digit, the PES endpoint shall evaluate whether sufficient digits have been collected to form a valid 
sequence according to the dialling plan in force: 

• If the accumulated digits do not correspond to a valid number but receipt of additional digits may lead to a 
valid number, the PES Endpoint shall continue monitoring incoming digits. This step may be repeated several 
times, until a valid number has been collected or the user has abandoned the call attempt by going back 
on-hook. 

• If the accumulated digits do not correspond to a valid number and receipt of additional digits cannot lead to a 
valid number, the PES Endpoint shall initiate call clearing during off -hook procedure as specified in 
clause 9.3. 1.3. 1.3. 

• If the accumulated digits correspond to a complete number, the PES endpoint shall: 

send a Setup-Request primitive to the Feature Manager. SDP information shall be set according to the 
information received in the response to the Add command; 

start monitoring the flash-hook event and continue monitoring the on-hook event. 

wait for either of these events and for events from the Feature Manager. Proceed to step 2 on the 
occurrence of any of these events. 

• If no digits are received, the PES endpoint shall initiate call clearing during off-hook (clause 9.3.1.3.1.3) 
unless the subscriber profile (see annex A) contains a no-dialling-behaviour = deferredCallSetup indication. In 
the latter case the PES endpoint shall: 

continue monitoring the on-hook event; 

send an empty Setup Request primitive to the Feature Manager; 

wait for either the on-hook event or an event from the Feature Manager. Proceed to step 2 on the 
occurrence of any of these events. 

Step 2(Outgoing Seizure - after sending of digits) 

On receipt of the notification of the on-hook event, the PES endpoint shall send a Session-Release-Request primitive 
to the Feature Manager and complete call clearing procedures during on-hook (clause 9.3.1.3.1.2). 

On receipt of the notification of the flash-hook event, the PES endpoint shall notify its Feature Manager using a 
Feature Request primitive. 

On receipt of a Session Progress primitive from the Feature Manager without alerting indication, the PES endpoint 
shall: 

• If the primitive contains an early media indication, modify the media path configuration accordingly so that 
the calling party can perceive in band information. 

• If the primitive does not contain an early media indication, ignore the event. 

• Remain in the same state. 
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On receipt of a Session Progress primitive from the Feature Manager indicating alerting, the PES endpoint shall: 

• If the primitive contains an early media indication, modify the media path configuration accordingly so that 
the calling party can perceive in band information. 

• If the primitive does not contain an early media indication, generate a ringback tone on the subscriber line. 

• Proceed with step 3. 

On receipt of an internal Setup-Response primitive reporting a busy condition, the PES endpoint shalllnitiate call 
clearing during off -hook procedure (clause 9.3.1.3.1.3). 

NOTE: In this case a busy tone is applied at the start of the clearing procedure. 

On receipt of an internal Setup-Response primitive reporting that no response has been received from the destination, 
the PES endpoint shall: 

• Initiate Call Clearing during off -hook procedure (clause 9.3.1 .3.1 .3). 

On receipt of an internal Setup-Response primitive reporting any other failure condition, the PES endpoint shall: 

• Initiate Call Clearing during off -hook procedure (clause 9.3.1 .3.1 .3). 

On receipt of an internal Setup-Response primitive reporting answer from the destination, the PES endpoint shall: 

• Modify the media path configuration to enable bi-directional traffic. 

• Store the properties associated to the IP side of the media path for use when sending traffic to the remote side. 

• As an operator's option request apply polarity reversal on the subscriber line. 

• Proceed with step 4. 

Step 3(Outgomg Seizure - provisional response received) 

On receipt of the on-hook event, the PES endpoint shall send a Session-Release-Request primitive to the Feature 
Manager and complete call clearing procedures as specified in clause 9.3.1.3.1.2. 

On receipt of the notification of the flash-hook event, the PES endpoint shall notify the feature manager using a 
Feature Request primitive. 

On receipt of an internal Setup-Response primitive reporting that no response has been received from the destination or 
any other failure, the PES endpoint shall: 

• Stop the ring back tone if application of this signal had been requested before. 

• Send a Session-Release-Request primitive to the Feature Manager and complete Call Clearing procedures as 
specified in clause 9.3.1.3.2.2. 

On receipt of an internal Setup-Response primitive reporting answer from the destination, the PES endpoint shall: 

• Modify the media path configuration to enable bi-directional traffic, if not performed previously. 

• Store the properties associated to the IP side of the media path for use when sending traffic to the remote side. 

• As an operator's option request the PES media gateway to apply the polarity reversal on the subscriber line. 

• Proceed with step 4. 

Step 4 (Outgoing session established) 

On receipt of an internal Session-Release-Request primitive from the Feature Manager, the PES endpoint shall initiate 
the call clearing during off-hook procedure (clause 9.3.1.3.1.3). 

On receipt of an internal Charging-Indication primitive, the PES endpoint shall either: 

• Generate metering pulses by rules described in clause C.2. 
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• Build an Advice Of Charge message (see ES 200 659-3 [10]) by rules described in annex D and transmit this 
message over the subscriber line using the procedures for off-hook data transmission specified in 

EN 300 659-2 [58]. 

On receipt of an internal Session-Update primitive, the PES endpoint shall modify the properties of the media path 
accordingly. 

On receipt of the on-hook event, the PES endpoint shall send a Session-Release-Request primitive to the Feature 
Mananger and complete call clearing procedures as specified in clause 9.3.1.3.1.2. 

On receipt of the notification of the flash-hook event, the PES endpoint shall notify the feature manager. 

9.3.1 .3.1 .2 Call Clearing upon On-Hook 

On receipt of a Session-Release-Confirm primitive from the Feature Manager the PES endpoint shall: 

• If polarity reversal was applied on the line when entering the active phase, then apply normal polarity to the 
line. 

• Release the analog line. 

• Proceed with step 0. 

On receipt of a Session-Release-Suspend primitive from the Feature Manager the PES endpoint shall start monitoring 
the off -hook event. If the off -hook event is detected, the PES endpoint shall send a Session-Resume primitive to the 
Feature Manager and re-enter Step 4 of the previous phase. 

9.3.1 .3.1 .3 Call Clearing during Off-Hook 
Upon entering this step, the PES endpoint shall: 

• Generate an appropriate announcement or tone (e.g. busy tone, congestion tone etc.) on the subscriber line. 

• If polarity reversal was applied on the termination in Step 3, then apply normal polarity to the line. 

• Release all IP resources associated to the session. 
Upon detection of the on-hook event, the PES endpoint shall: 

• Release the analog line. 

• If a Session Release-Request primitive has been previously received from the Feature Manager, then send a 
Session-Release-Confirm to the Feature Manager. 

• Proceed with step 0. 

If the calling party is still off-hook upon end of announcement or tone, generate an off -hook warning tone on the 
subscriber line after expiry of a network configured timer. Upon termination of the off-hook- warning tone, the PES 
endpoint may, as a network option, apply reduced power feed to the line after expiry of a network-defined timer. 

9.3.1 .3.2 Terminating side procedures 

9.3.1.3.2.1 Call Initiation 

Step (IDLE) 

On receipt of a Setup-Request primitive from the internal SIP UA (via the Feature Manager), the PES endpoint shall: 

• Check that the required bearer service is compatible with analogue lines, otherwise return a Setup-Response to 
the Feature Manager, with a reject indication. 

• Determine which physical line(s) are associated with the target public user identity. 
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• If no physical line is associated with the called party, the PES endpoint shall send a Setup-Response primitive 
with a failure indication to the internal SIP UA via the Feature Manager. If a single line is associated to the 
target public user identity, select this line otherwise if multiple lines are associated to the target public user 
identity, select one line. 

• Check the administrative status of the selected line. If the line is out of service, the PES endpoint shall send a 
setup-response primitive with a failure indication to the internal SIP UA via the Feature Manager or select 
another line if multiple lines are associated to the called number. If all lines are out of service, the PES 
endpoint shall send a Setup Response primitive with a failure indication to the internal SIP UA via the Feature 
Manager. 

• Check whether the selected line is already engaged in a call. 

NOTE 1 : The algorithm for selecting a line in case multiple lines are associated to the same called number (fixed 
priority, round-robin, etc.) is outside the scope of the present document. 

NOTE 2: It is expected that only one line will be associated to a public user identity when the tight-coupling mode 
is used. 

If the selected line is not engaged in a call, the PES endpoint shall: 

• Allocate IP resources, based on the session description information received in the Setup-Request. 

• Add the physical line representing the called party's line to the newly created context. 

• Apply ringing to the subscriber line. If information has to be displayed on the terminal, the procedure for 
on-hook "data transmission during ringing or prior to ringing" as specified in EN 300 659-1 [57] shall be 
applied and the block of data to be displayed shall be set as specified in annex D. As directed by the AS (with 
a SIP Alert-Info header in the INVITE request), the PES endpoint may apply a distinctive ringing tone. 

• Send a Session-Progress (Alerting) primitive to the Feature Manager. 

• Start a no-answer timer. 

• Start monitoring the off-hook event 

• Proceed to step 1 . 

If the selected line is already engaged in a call and multiple lines are associated to the same called number, select an 
alternative line and repeat the above procedures. 

If the selected line is already engaged in a call and there is no alternative "in-service" line that can be selected, the PES 
endpoint shall either: 

• Send a Setup-Response (busy) primitive to the Feature Manager if an explicit indication that the Call Waiting 
service is not provisioned to the user has been received as part of the profile delivery procedure or as a 
network option if the incoming Setup-Request does not contain a MIME body indicating that the terminating 
user is subscribed to the Call Waiting service as defined in TS 124 615 [44]; or 

• Initiate a call waiting procedure: 

Allocate IP resources, based on the session description information received in the Setup-Request. 

Apply the call waiting tone to the subscriber line. If information has to be displayed on the terminal, the 
procedure for off-hook data transmission as specified in EN 300 659-2 [58] shall be applied and the 
block of data to be displayed shall be set as specified in annex D. As directed by the AS (with a SIP 
Alert-Info header in the INVITE request), the PES endpoint may apply a distinctive call waiting tone. 

Send a Session-Progress (Alerting) primitive to the Feature Manager, including 
'urn:alert:service:call-waiting' to be inserted in the Alert-Info header field of the corresponding SIP 

message. 

Start a call-waiting timer. 
Proceed to step 1 . 
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If a Session-Release-Request primitive is received from the internal UA, via the feature manager, the PES endpoint 
shall: 

• Release IP resources associated with the call. 

• Release the analog line. 

• Send a Session-Release-Confirm primitive to the Feature Manager. 
Step 1 (Incoming Seizure) 

If an off -hook event is notified, the PES endpoint shall: 

• Start monitoring the following events: 

the flash-hook event; 
the on-hook event. 

• Report the occurrence of the off-hook event to the Feature Manager. 

• Proceed to step 2. 

If the no-answer timer (line free) or call-waiting-timer (line busy) expires, the PES endpoint shall: 

• Send a Setup-Response (no answer) primitive to the internal UA via the Feature Manager. 

• Stop the signal sent to the called party (ringing or call waiting signal). 

• Stop the signal sent to the calling party (ring back tone or the announcement). 

• Release the analog line, unless it is already engaged in another call. 

• Send a Session-Release-Request primitive to the Feature Manager and complete call clearing procedures as 
specified in clause 9.3.1.3.2.2. 

Step 2 (Incoming Session established) 

If the flash-hook event is detected, notify the Feature Manager using a Feature Request primitive. 

On receipt of an internal Session-Update primitive, the PES endpoint shall modify the properties of the media path 
accordingly. 

If the on-hook event is detected, the PES endpoint shall send a Session-Release-Request internal primitive to the 
Feature Manager and complete call clearing procedures as per clause 9.3.1.3.2.2. 

If a Session-Release-Request primitive is received via the Feature Manager from the internal UA, the PES endpoint 
shall initiate call clearing during off-hook procedure (clause 9.3.1.3.2.3). 

9.3.1 .3.2.2 Call Clearing upon On-Hook 

On receipt of a Session-Release-Confirm primitive from the Feature Manager the PES endpoint shall: 

• Release IP resources associated with the call. 

• Release the analog line. 

• Proceed with step 0. 

On receipt of a Session-Release-Suspend primitive from the Feature Manager the PES endpoint shall start monitoring 
the off-hook event. If the off-hook event is detected, the PES endpoint shall send a Session-Resume primitive to the 
Feature Manager and re-enter Step 2 of the previous phase. 
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9.3.1 .3.2.3 Call Clearing during Off-Hook 

Upon entering this step, the PES endpoint shall: 

Release IP resources associated with the call. 

Generate an appropriate announcement or tone (e.g. busy tone, congestion tone etc.) on the subscriber line. 
On receipt of the on-hook event, the PES endpoint shall: 

Release the analog line. 

Report the occurrence of the on-hook event to the Feature Manager using a Session-Release-Confirm 
primitive if a Session-Release-Request had been previously received. 

Proceed with step 0. 

If the called party is still off-hook upon end of the announcement or tone, apply the off-hook warning tone on the 
subscriber line after a network configured timer. Upon termination of the off-hook-warning tone, the PES endpoint 
may, as a network option, apply reduced power feed to the line after expiry of a network-defined timer. 

9.3.1 .4 Procedures for fax/modems calls over analogue access 

In order to be able to properly handle fax and modem calls, the PES endpoint monitors the fax and modem tones listed 
inTS 183 002 [5], table 92. 

Upon detection of a fax or modem tone, the PES Endpoint notifies the Feature Manager if the recognized tone 
corresponds to a supported fax/modem. Otherwise, the event is discarded. 

NOTE: Modelling of the Feature Manager behaviour for transitioning between Audio mode and VBD mode 
requires further studies. Alignment with TS 183 002 [5] requires further studies as well. 

9.3.1 .5 Message Waiting Indication for analogue access 

On receipt of a Service Notification internal primitive reporting the "message-summary" event, the PES endpoint shall 
transmit the message indication to the analog line using on-hook "data transmission not associated with ringing" 
procedures defined in EN 300 659-1 [57] and the block of data shall be set as specified in annex D. The terminal 
alerting signal may be provisioned on a per line or global basis. If the line is off-hook, the PES Endpoint shall transmit 
the message indication only upon detecting that the line changed to on-hook. 

9.3.2 PES Access Point 

The PES Access point controls and is aware of analog signalling events through the PES Media Gateway, using the 
H.248 protocol as specified in clause 7. 

9.3.3 PES Media Gateway 

The PES media gateway shall support the H.248 procedures specified in TS 183 002 [5] appropriate to an MG. 



£75/ 



67 ETSI TS 1 83 043 V3.4.1 (201 1 -04) 



Annex A (normative): 

XML document structure for Profile Delivery 

Profile documents are sub-trees of the simservs XML document defined in TS 124 623 [33]. The following schema 
shall be used to describe XML documents that specify the profile elements applicable to an endpoint. 

The .xsd file is contained in archive ts_183043v030401p0.zip which accompanies the present document. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns : ss="http : //uri . etsi .org/ngn/params/xml/simservs/xcap" 

xmlns :xs="http: //www.wS . org/2 001/XMLSchema" 

targetNamespace="http : //uri .etsi .org/ngn/params/xml/simservs/xcap" elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : complexType name="simservType" > 

<xs : attribute def ault="true" name="active" type="xs iboolean" use="optional" /> 
<xs : anyAttribute namespace="##any" processContents="lax" /> 
</xs : complexType> 

<xs : element name=" dial -tone -management" substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs :documentation>Dial Tone Management 
</xs : documentation> 
</xs : annotation> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<xs : element name=" dial -tone -pat tern" def ault=" standard-dial -tone" 
minOccurs=" 0" > 

<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value=" standard-dial- tone" /> 
<xs : enumeration value=" special-condition- tone" /> 
<xs : enumeration value="message-waiting-tone"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element> 

<xs:element name="mcid-service" def ault="mcid-service-withdrawn" minOccurs=" 0" > 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value= "moid- service-provisioned" /> 
<xs : enumeration value= "moid- service-withdrawn" /> 
</xs : restriction> 
</xs : simpleType> 

</xs : element > 

<xs:element name="no-dialling-behaviour" def ault="rejectCall" minOccurs=" 0" > 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value="rejectCall"/> 

<xs : enumeration value="immediateCallSetup"/> <xs : enumeration 

value="def erredCallSetup"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name="hold-service" def ault="hold-service-provisioned" minOccurs="0"> 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value=" hold- service-provisioned" /> 
<xs : enumeration value=" hold- service- withdrawn" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : element> 

<xs:element name="toggle-service" def ault=" toggle- service-withdrawn" minOccurs="0" > 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value=" toggle- service-provisioned" /> 
<xs : enumeration value=" toggle- service-withdrawn" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : element> 
<xs : element name=" three -pty- service" def ault="three-pty- service- withdrawn" minOccurs="0" > 
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<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value="three-pty-service-provisioned"/> 
<xs : enumeration value="three-pty- service-withdrawn" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name="cw-service" def ault="cw-service-provisioned" minOccurs="0" > 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value="cw-service-provisioned"/> 
<xs : enumeration value="cw- service- withdrawn" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name="priority-line" def ault="priority-line-disabled" minOccurs="0" > 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value= "priority- line- enabled" /> 
<xs : enumeration value= "priority- line-disabled" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs : element name=" on- hook-behaviour- calling- subscriber" minOccurs="0" > 
<xs : complexType> 
<xs : sequence> 

<xs : element name=" on- hook-behaviour- calling- subscriber- flag" minOccurs="0"> 
<xs : simpleType> 
<! --Default value is network specific --> 
<xs : restriction base="xs : string" > 

<xs : enumeration value="release-calling-subscriber"/> 
<xs : enumeration value="hold-calling-subscriber"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name="suspend-timer" type="xs : integer" minOccurs="0" > 
</xs : element > 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : element name=" on- hook-behaviour- called- subscriber" minOccurs = " 0" > 
<! --Default value is network specific --> 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value="release-called-subscriber"/> 
<xs : enumeration value="hold-called-subscriber"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 
</xs : schema> 
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Annex B (normative): 
AGCF/VGW Feature Manager 

B.1 Void 

B.2 Void 

B.3 Void 

B.4 Feature manager behaviour 
B.4.1 Registration procedures 

Based on the information received from the MGC and local configuration data (mapping between line identities and 
IMS identities, authentication parameter, etc.) the Feature Manager requests the SIP UA component to initiate 
appropriate SIP registration procedures (per line registration, group registration). 

There may a lot of terminations to register and deregister at the same time from the MGC side. In order to avoid the 
impact of the flood registration and deregistration on the IMS core network, the Feature Manager may use some 
mechanism to control the number of registration/deregistration during a specified period of time. 

B.4.1 .1 Group state change procedures 

On receipt of a ServiceChange internal primitive indicating "restart", the Feature Manager sends one or more 
Register-Request primitives to the SIP UA. 



On receipt of a ServiceChange internal primitive indicating "forced" or "graceful", the Feature Manager sends one or 
more Deregister-Request primitives to the SIP UA. 

The number of primitives sent to the SIP UA depends on the AGCF/VGW configuration with regards to identity 
management. The following two cases are identified and lead to different procedures: 

• One private user identity is assigned to the VGW or AGCF (or each MGF). 

• A private user identity is associated with each termination. 

In the first case, the Feature Manager sends a single primitive with the private user identity associated with the VGW or 
AGCF (or the MGF) and a temporary public user identity. The public user identities will be implicitly registered or 
deregistered using implicit registration procedures defined in TS 124 229 [4]. 

In the second case, the Feature Manager sends one primitive for each termination connected to the MGF that caused the 
service change event. 
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B.4.1 .2 Per line/access state change procedures 

B.4.1 .2.1 User-initiated state change transition to "In service" stat 

On receipt of a Service-Change internal primitive from the MGC component indicating "Restart", the Feature Manager 
shall: 

• Lookup the configured data for the public user identities and the private user identities of the related users. 

• If the related users have not been registered, use a Register-Request primitive to request the SIP UA to initiate 
appropriate SIP registration procedures. 

B.4.1 .2.2 User-initiated state change to "Out of service" state 

On receipt of a Service-Change internal primitive from the MGC component indicating "Graceful" or "Forced", the 
Feature Manager shall: 

• Lookup the configured data for the public user identities and the private user identities of the related users. 

• If the related users have been registered, use a Deregister-Request primitive to request SIP UA to initiate 
appropriate SIP deregistration procedures. 

B.4.1. 2. 3 Exception procedures 

On receipt of a Service-Change internal primitive from the MGC component indicating that the communication 
between the AGCF and the MGF has been lost, the Feature Manager shall use the Deregister-Request primitive to 
request the SIP UA to initiate appropriate SIP deregistration procedures for all the registered users belong to the MGF. 

In order to avoid the impact of the flood deregistration on the IMS core network, the Feature Manager may use some 
mechanism to control the number of deregistration during a specified period of time. 

B.4.2 Flash Hook Management 

B.4.2.1 Void 

B.4.2. 2 Flash-Hook Management for analogue access 

B.4.2.2.1 General rules 

Flash-hook events detected by the line side of the AGCFA'^GW are reported to the feature manager using a Feature 
Request internal primitive. 

For the processing of flash-hook event notifications two different methods exist: 

• Loose Coupling Method. 

• Tight Coupling Method. 

Among others, the methods determine the degree of autonomous processing in the AGCF/VGW after the notification of 
the flash-hook event to the PES Application Server. 

The execution of the service independent feature logic is common for both methods of flash-hook management up to 
the point in time flash-hook is detected. 
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Both methods are reflected in separate clauses of clause B.4.2.2 for flash-hook management principles and in annex C 
for individual supplementary services. The different methods can be characterized as follows: 

• Loose Coupling: 

The AGCF/VGW implements service-independent feature logic for dealing with register recall events. By 
evaluating call context and UA profile information, it can make certain decisions such as whether or not to 
apply dial tone on register recall, collect digits (SOC or SCC), put a party on hold etc. The AS perceives the 
AGCF/VGW almost as if it was a regular IMS client accessing PSTN/ISDN simulation services. 

• Tight Coupling: 

The AS is assumed to have full control over the service. The AGCF/VGW does not implement any 
service-independent feature logic for dealing with register recall events and does not require UA profile 
information. The PES AS takes the decisions on the service behaviour (e.g. whether or not to apply dial tone 
and collect digits), manipulates call legs as needed and instructs the AGCF/VGW on how to proceed based on 
appropriate SIP messages. 

The decision to implement tight coupling or loose coupling is left to the network operator. However, it is important that 
both the AGCF/VGW and the PES application server are configured the same way. 

B.4.2.2. 2 Loose coupling procedures 

Processing of a Feature-Request depends on the call configuration. 
Call Configuration: 1-party 

In this configuration, an unconfirmed INVITE dialog exists between the SIP UA and another endpoint. 

On receipt of a Feature Request from the MGC component, unless an explicit indication that the HOLD service is not 
provisioned to the user has been received as part of the profile delivery procedure, the Feature Manager shall request the 
MGC component to interact with the media gateway in order to play a dial tone and collect digits. 

If the digit collection succeeds, the Feature Manager shall request the SIP UA to send an INVITE request to the PES 
application server, with the collected digits as Request-URL Otherwise, the events shall be discarded. 

Call Configuration: Stable 2-party 

In this configuration, one confirmed INVITE dialog exists between the SIP UA and another endpoint. 

Processing flash-hook notifications depend on whether MCID can be invoked using this command or not. In networks 
where MCID is invoked by other means the Feature Manager shall proceed to step 1 . 

In networks, where MCID is invoked using a flash hook event, the Feature Manager shall check whether MCID is 
provisioned for the served user. If MCID is provisioned, the Feature Manager shall proceed to step 2 otherwise it shall 
proceed to step 1 . 

1) On receipt of a flash-hook notification from the MGC component, unless an explicit indication that the HOLD 
service is not provisioned to the user has been received as part of the profile delivery procedure, the Feature 
Manager shall: 

Request the SIP UA to send a re-INVITE request towards the connected party (B party). The re-INVITE 
request is built as follows: 

■ The Request URI is set to the B party's identity. 

■ The SDP description for the active media stream is set to a=sendonly. 

NOTE 1 : This information may be used by an AS to request the sending of an announcement to the B Party. 

Request the MGC component to initiate an outgoing call process as if an off-hook event had been 
received. 
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2) The handling of MCID in stable 2-party configuration depends on the network configuration. 

If the MCID service is provisioned and requires initial flash-hook detection then the Feature Manager on 
receipt of flash-hook notification from the MGC component shall follow one of the following options: 

■ assume direct invocation of MCID; or 

■ initiate the collection of a feature code and request the MGC component to interact with the media 
gateway in order to: 

Set the stream mode of the IP media termination to "inactive". 

Play a dial tone. 

Collect a feature code. 

If the collected feature code indicates MCID or if no feature code is required, the Feature Manager shall 
request the SIP UA to send a re-INVITE request towards the AS. The re-INVITE request is built as 
follows: 

■ the Request URI is set to the served user's identity, and 

■ include no Body in the re-INVITE; or 

■ as a network operator option a re-INVITE including a XML-MIME with XML mcid body with 
MCID XML Request schema containing a McidRequestlndicator set to 1 . 

If the collected feature code does not indicate MCID, the Feature Manager shall ignore the flash-hook 
notification. 

Call Configuration: Stable 2-party call with additional held/waiting party 

In this configuration, a confirmed INVITE dialog exists between the SIP UA and some other endpoint (the "active 
party", and either an unconfirmed dialog exists with a third endpoint (the "waiting party"), or another confirmed dialog 
exists with a third party that is on hold ("held party"). 

On receipt of a flash-hook notification from the MGC component, the Feature Manager shall request the MGC 
component to interact with the media gateway in order to: 

• Set the stream mode of the IP media termination to "inactive". 

• Play a dial tone. 

• Collect a feature code. 

The number of digits is provisioned in the AGCF/VGW. The AGCF/VGW shall also send a re-INVITE request on the 
initial dialogue to hold the associated media stream, as described in TS 124 610 [8]. 

As a Network operator option the sending of a re-INVITE to set the active party to inactive is delayed until the feature 
logic verifies that the collected feature code is valid. 

NOTE 2: This information may be used by an AS to request the sending of an announcement to the B Party. 

With loose coupling, the AGCF/VGW provides call processing logic to manipulate call legs, much like a simulation 
endpoint would operate. 

The Feature Manager analyses the feature code according to a local mapping table. For each feature code, this table 
indicates the user expected feature: 

• The served user wishes to be connected to a particular held/waiting party and keep the other party 
held/waiting. 

• The served user wishes to be connected to a particular held/waiting party and release the other party. 

• The served user wishes to establish a 3-party conference with both of the other parties. 

• The served user wishes invoke the MCID service. 
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If the feature code received does not match any known feature, the FM ignores the feature code and optionally requests 
the MGC component to interact with the media gateway in order to play an error tone or an announcement to the served 
user. 

As a network option when an additional Flash-Hook command received a new dial tone is played and feature code can 
be received by the MGC component and processed by the AGCF/VGW. 

If the feature code received indicates that the served user wishes to be connected to a particular held/waiting party, 
unless an explicit indication that the Call Toggle service is not provisioned to the user has been received as part of the 
profile delivery procedure, the Feature Manager shall: 

• Request the SIP UA to send either: 

a 200 OK response to the INVITE request received from the waiting party if the dialogue is not 
confirmed yet; or 

a re-INVITE request if the dialogue with the held party is already confirmed. The Re-INVITE request is 
built as follows: 

■ The Request URI is set to the held party's identity. 

■ The SDP description for the active media stream is set to a=sendrecv. 

• If a AGCF is in use then request the MGC component to interact with the media gateway in order to: 

modify the Remote Descriptor of the ephemeral termination according to the SDP information received 
from the held/waiting party; 

set the Stream Mode of the IP media termination to sendrecv; 

monitor the flash-hook event on the physical termination. 

• If a VGW is used then: 

modify the IP media termination according to the SDP information received from the held/waiting party; 

set the Stream Mode of the IP media termination to sendrecv; 

monitor the flash-hook event on the physical termination. 

If the feature code received indicates that the served user wishes to release the call with the other held/waiting party, the 
Feature Manager shall: 

• Request the SIP UA to send a 603 response or a BYE request to the waiting/held party depending on the 
dialogue state. 

• Request the MGC component to interact with the media gateway in order to monitor the flash-hook event on 
the physical termination. 

If the feature code received indicates that the served user wishes to establish a 3-party conference, unless an explicit 
indication that the 3PTY service is not provisioned to the user has been received as part of the profile delivery 
procedure, the Feature Manager shall: 

• Request the MGC component to interact with the media gateway in order to add a termination to the current 
context based on SDP information associated with the initial held party (i.e. the party that was already held 
before the flash-hook has been detected). 

• Request the SIP UA to send a re-INVITE request towards each of the held/waiting parties. The re-INVITE 
request is built as follows: 

the Request URI is set to the held/waiting party's identity; 

the SDP description for the active media stream is set to a=sendrecv. If an AGCF is in use the address 
and port are set according to the contents of the local descriptor of the termination representing this party 
on the media gateway. Or if a VGW is in use then the address and port are set according to the SDP 
description of the IP media termination representing this party. 
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If the feature code received from the internal MGC component indicates that the served user wishes to invoke MCID, 
the Feature Manager shall request the SIP UA to send a re-INVITE request towards the AS. The re -INVITE request is 
built as follows: 

• The Request URI is set to the served user's identity; and: 

include no Body in the re-INVITE; or 

as a network operator option a re-INVITE including a XML-MIME with XML mcid body with MCID 
XML Request schema containing a McidRequestlndicator set to 1 . 

B.4.2.2.3 Tight coupling procedures 
B.4.2.2.3.1 Introduction 

With tight coupling procedures, all collected digits are reported to the PES application server and the AS determines the 
appropriate call processing actions to take. Manipulation of call legs for call waiting and 3-party calls is managed by the 
AS, so feature logic for these services is not required in the AGCF/VGW. Unlike loose coupling, where a flash-hook 
notification must be followed by dialled digits in order for the AGCFA'GW to generate an INVITE request, tight 
coupling procedures specify the reporting of a flash-hook event without additional digits dialled by the user. 

NOTE: Due to the procedures for profile delivery described in clauses 5.3. L2 and 5.3.2.2 the dial tone is 
provisioned in the AGCF/VGW. 

B.4.2.2.3. 2 Flash-Hook Reporting 

On receipt of a Feature Request from the MGC component, the Feature Manager shall request the SIP UA to create a 
new dialogue and send an INVITE (flash) request to the Application Server, built as follows: 

• The Request URI is structured as follows: 

A user part containing a unique value that signifies that a flash-hook event was detected (such as 
flash@pes-scc.operator.com) . 

When hook- flash is reported to the AS, it may, as a network option, instruct the AGCF/VGW to perform 
digit collection and provision of dial tone (see clause B.4.2.2.3.2A). Alternatively it may instruct another 
entity under its control such as a Media Resource Function to perform digit collection and provision of 
dial tone as described in annex G. 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile (see annex C). 

• A P-Asserted-Identity (AGCF) or a P-Preferred-Identity may be sent (VGW) containing the public identity of 
the subscriber requesting the service. If the P-Preferred-Identity is not send then the PES Endpoint shall ensure 
that the From header contains the equivalent identity. 

• An SDP offer for a voice call. 

One of the following actions is determined by the Application Server and indicated to the VGW/ AGCF by appropriate 
SIP responses. The list is not assumed to be complete, but covers the most likely responses: 

• 484 Address Incomplete with XML attachments indicating: 

the dial-tone pattern to be applied, if needed for service logic; 

a minimum number of digits to be collected. 

NOTE: The definition of the XML schema for dial-tone pattern and minimum number of digits is for further 
study. 
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200 OK 



if the 200 OK contains a SDP (a=inactive) indicating that no path has to be switched then the flash-hook 
alone has determined the service, no further action has to be performed by the AGCF/VGW. e.g. for 
simplified Call Waiting; 

if the 200 OK returns a SDP (sendrecv, recvonly,) response then the AGCF/VGW will switch the 
corresponding media path (e.g. dial-tone may be sent by an MRF and inband digit collection at MRF will 
happen). 

• 403 Forbidden 

indicates that there is no flash-hook invoked service supported on this line. The AGCF/VGW will not 
apply dial-tone and suppress any dialled digits. It is a network option how to proceed. For example, 
whether to revert back to active communication, provide an announcement or perform any other action. 

• 503 Service Unavailable 

indicates that the call request will not be processed (e.g. due to an overload condition in the core 
network). From the end-user perspective, the flash-hook will just be ignored. It is a network option how 
to proceed. For example, whether to revert back to active communication, provide an announcement or 
perform any other action. 

B.4.2.2.3.2A Digit Collection and Reporting 

If a 484 Address Incomplete message with XML attachment is received, the AGCF/VGW applies the indicated dial 
tone and collects the indicated number of digits. The collected digit(s) are reported to the AS as the user part of the 
Request-URI of a re-INVITE request on that same dialogue in which the flash-hook event was reported. The domain 
name of the request-URI is the same than for reporting the flash-hook event. 

Inter-digit timer values are assumed to be provisioned in the AGCF/VGW. If a timer expires before the minimum 
number of digits is collected the AGCF/VGW sets the user part to "null". 

If no minimum number of digits is indicated in the XML attachment or no XML attachment is received, a default value 
of "one" is assumed. If no dial tone is indicated, the AGCF/VGW uses the dial tone pattern received as part of the user 
profile delivery procedure or a default dial tone if none was received. 

B. 4. 2. 2. 3. 3 Behaviour and Functional Distribution 

In the following the principles of behaviour and functional distribution are described: 

• Multiple dialogs on A-side: 

When a subscriber goes off-hook the AGCF/VGW will create a new dialog. 

Release of the dialogue opened for the purpose of sending the feature code is the responsibility of the 
apphcation server. 

NOTE: The 199 (Early Dialog Terminated) response code may be used to terminate the dialog. This may be 
specified in a future Release. 

• Mid call digit and SOC collection: 

The entity collecting the digits shall also generate the dial tone. Those functions can either be performed 
by the AGCF/VGW or an MRF. 

• The fact whether a SOC has to be collected or a regular telephone number can be determined in one of the 
following ways, depending on whether the 484 response is including a min-nr-digits -required parameter or 
not: 

484 including a min-nr-digits -required parameter: 

The min-nr-digits-required parameter in the 484 response will indicate the number of digits to be 
collected. The AGCF/VGW notifies the AS as soon as the indicated number of digits is available. No 
digit map is required in this case. 
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484 not including a min-nr-digits-required parameter: 

The AGCF/VGW always sends the first digit irrespective of whether a SOC has to be collected or a 
regular telephone number has to be dialled. The AS controls subsequent actions by appropriate responses 
as for instance another 484. 

• Putting the remote party on-hold: 

The AS is assumed to take this decision dependent on service logic and to take the necessary 
steps triggered by a received flash-hook INVITE. 

• The following elements of the UA profile document defined in annex A are not needed as a result of using a 
tight-coupling approach: 

Mcid-service 

Hold-service 

Toggle-service 

Three-pty-service 

Cw-service 

• Announcement generation: 

Typically the AS can determine whether an announcement has to be played or not. 

In cases where the VGW needs to invoke an announcement, then the announcement is requested by a 
dedicated request URI indicating the announcement type. 

• AGCF/VGW media gateway control: 

For an AGCF the Feature Manager shall request the MGC component to interact with the media gateway 
in order to modify the H.248 Remote Descriptor and stream mode according to the SDP information 
received in re-INVITE messages sent by the Application Server. 

For a VGW the Feature Manager shall request the MGC component to interact with the media gateway 
component within the VGW in order to modify the IP media termination according to the SDP 
information received in re-INVITE messages sent by the Application Server. 

Release of the dialogue opened for the purpose of sending the feature code is the responsibility of the application server: 

• Establishment of second call fails for CW or 3-party call: 

If the user aborts dialling to user C via flash-hook then the AS should keep the held party and trigger the 
AGCF/VGW to play the appropriate tone to the user or initiate an announcement via a MRF. 

If the call to user C has failed (dialling aborted, busy at user C, unknown destination number) and the 
user A goes on-hook then the AS should keep the held party and apply re-ringing to user A. 

On receipt of a feature code which is unknown or cannot be executed by the AS the AS should 
re-connect the original call by sending a re-INVITE request to user A with appropriate SDP settings or, 
as a network option, request an MRF to play an announcement. In the latter case, the subscriber can retry 
by invoking flash-hook or going on-hook (followed by re-ring). 

B.4.3 Behaviour of Re-ringing 

In the following example re-ringing is described: 

• Re-ringing after Hold/Waiting: 

Call Configuration: Stable 2 party call with additional held/waiting party. 
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If in the normal situation with one active and one held call, the served user (whether or not he is the 
called user) goes on-hook, the currently connected call shall be released, and the served user shall be 
rerung immediately for the held call. The held party continues to be held during the ring back period. 
When the served user answers before the 'CW No Answer timer' expires a normal two party call is 
established. 



B.4.3.1 Loose coupling 



When the served user goes on hook, clause B.4.4.2.1 or clause B. 4.4. 3.1 applies. When the active call is cleared, the 
Feature manager knows that there is still a held session and alerts the served user in order to re-establish this session. 
When the served user accepts the call, the feature manager shall send a re-INVITE to the held party in order to 
re-establish the session. 



B. 4.3.2 Tight coupling 



When the served user goes on hook, clause B. 4.4. 2. 2 or clause B.4.4.3.2 applies. When the active call is cleared, the 
application server of the served user knows that there is still a held session and sends an INVITE to the served user in 
order to re-establish this session. 

B.4.4 On-Hook Management 
B. 4.4.1 General 
B.4.4.1.1 General rules 

On-hook events detected by the line side of the AGCFA'^GW are reported to the feature manager using a Session- 
Release-Request internal primitive. 

The behaviour of the feature manager depends on whether the loose coupling or tight coupling mode is used and 
whether the primitive is received on behalf of an originating or terminating party. 

B.4.4. 1 .2 Interaction with other services 

When the subscriber goes On-hook and a Re-Ring condition exists, the Call Held service is not applicable. 

NOTE: The Re-Ring conditions exist when a call is in a "stable 2 party call with additional held/waiting party 
state" and the subscriber goes On-hook. 

B.4.4. 2 Originating side procedures 
B.4.4.2.1 Loose coupling procedures 

On receipt of a Session-Release-Request primitive, the Feature Manager shall determine whether to apply the Call 
Held service depending on the user profile and the type of call. 

If no explicit indication is received as part of the profile delivery procedure, the Feature Manager determines whether 
the Call Held service is provisioned or not, based on a network option. 

If the Call Held service is provisioned, the type of call is evaluated. The Call Held service should be considered 
applicable for the following type of calls: 

• Emergency call (call to a Public Safety Answering Point). 

• As a network option: Other special numbers (e.g. call to operator). 

The emergency numbers (and optionally other special numbers) should be provisioned in the VGW/AGCF in order to 
enable type of call evaluation. 
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NOTE: An alternative method to identify the type of call maybe providing a called party category in Ixx or 200 
OK response. This is not specified in this release. 

If the Call Held service is applicable, the Feature Manager shall respond to the MGC component of the AGCF/VGW 
with a Session-Release-Suspend primitive and start a suspend timer. Otherwise, it shall respond with a Session- 
Release-Confirm primitive and send a Session-Release-Request primitive to the internal SIP UA. 

The value of the suspend timer may be received as part of the profile delivery procedure. Otherwise a default network 
specific value is used. 

If the suspend timer expires, the Feature Manager shall respond to the MGC component of the AGCF/VGW with a 
Session-Release-Confirm primitive and send a Session-Release-Request primitive to the internal SIP UA. 

If a Session-Resume primitive is received before the timer expires, the Feature Manager shall stop the suspend timer. 

B.4.4.2.2 Tight coupling procedures 

On receipt of a Session-Release-Request primitive, the Feature Manager shall determine whether to apply the Call 
Held service depending on the user profile and the type of call. 

If no explicit indication is received as part of the profile delivery procedure, the Feature Manager determines whether 
the Call Held service is provisioned or not, based on a network option. 

If the Call Held service is provisioned, the type of call is evaluated. The call held service should be considered 
applicable for the following type of calls: 

• Emergency call (call to a Public Safety Answering Point). 

• As a network option: Other special numbers (e.g. call to operator). 

The emergency numbers (and optionally other special numbers) should be provisioned in the VGW/AGCF in order to 
enable type of call evaluation. 

NOTE 1: An alternative method to identify the type of call maybe providing a called party category in Ixx or 
200 OK response. This is not specified in this release. 

If the Call Held service is applicable, the Feature Manager shall respond to the MGC component of the AGCF/VGW 
with a Session-Release-Suspend primitive and request the SIP UA to send an INVITE (on-hook) request on a new 
dialogue to the PES Application Server. 

If the Call Held service is not applicable, the Feature Manager shall respond to the MGC component of the 
AGCF/VGW with a Session-Release-Confirm primitive and send a Session-Release-Request primitive to the internal 
SIP UA. 

In all cases the INVITE (on-hook) request is built as follows: 

• The Request URI is structured as follows: 

A user part containing a unique value that signifies that a on-hook event was detected (such as 
onhook @pes-scc.operator.com ) . 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile (see annex C). 

• A P-Asserted-Identity (AGCF) or a P-Preferred-Identity may be sent (VGW) containing the public identity of 
the subscriber on behalf of whom the on-hook event is reported. 

NOTE 2: Upon receipt of the INVITE (on-hook) the Application Server can send a BYE request on the 

call-associated dialogue if the call is to be released or start a suspend timer and wait for another INVITE 
reporting the offhook event. If the suspend timer expires the Application Server can send a BYE request 
on the call-associated dialogue. 

• An SDP offer for a voice call. 
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If a Session-Resume primitive is received, the Feature Manager shall request to the SIP UA to send an INVITE (off- 
hook) request built as follows: 

• The Request URI is structured as follows: 

A user part containing a unique value that signifies that a off-hook event was detected (such as 
offhook @pes-scc.operator.com) . 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile (see annex C). 

• A P-Asserted-Identity (AGCF) or a P-Preferred-Identity may be sent (VGW) containing the public identity of 
the subscriber on behalf of whom the off-hook event is reported. 

• An SDP offer for a voice call. 

B.4.4.3 Terminating side procedures 
B.4.4.3.1 Loose coupling procedures 

On receipt of a Session-Release-Request primitve, the Feature Manager shall determine whether to apply the Call Held 
service depending on the user profile. If no explicit indication is received as part of the profile delivery procedure, the 
default value is network specific. 

If an indication that the Call Held service is not provisioned to the user has been received as part of the profile delivery 
procedure, the Feature Manager shall respond to the MGC component of the AGCF/VGW with a Session-Release- 
Confirm primitive and send a Session-Release-Request primitive to the internal SIP UA. 

Otherwise it shall respond to the MGC component of the AGCF/VGW with a Session-Release-Suspend primitive and 
start a suspend timer. 

If the suspend timer expires, the Feature Manager shall respond to the MGC component of the AGCF/VGW with a 
Session-Release-Confirm primitive and send a Session-Release-Request primitive to the internal SIP UA. 

If a Session-Resume primitive is received before the timer expires, the Feature Manager shall stop the suspend timer. 

B.4.4.3. 2 Tight coupling procedures 

On receipt of a Session-Release-Request primitve, the Feature Manager shall determine whether to apply the Call Held 
service depending on the user profile. If no explicit indication is received as part of the profile delivery procedure, the 
default value is network specific. 

If the Call Held service is provisioned, the Feature Manager shall respond to the MGC component of the AGCF/VGW 
with a Session-Release-Suspend primitive and request the SIP UA to send an INVITE (on-hook) request to the PES 
Application Server over a new dialogue. 

If the Call Held service is not provisioned, the Feature Manager shall respond to the MGC component of the 
AGCF/VGW with a Session-Release-Confirm primitive and send a Session-Release-Request primitive to the internal 
SIP UA. 

In all cases the INVITE (on-hook) request is built as follows: 

• The Request URI is structured as follows: 

A user part containing a unique value that signifies that a on-hook event was detected (such as 
onhook @pes-scc.operator.com) . 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile (see annex C). 

• A P-Asserted-Identity (AGCF) or a P-Preferred-Identity may be sent (VGW) containing the public identity of 
the subscriber on behalf of whom the on-hook event is reported. 
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NOTE: Upon receipt of the INVITE (on-hook) the Application Server can send a BYE request on the call- 
associated dialogue if the call is to be released or start a suspend timer and wait for another INVITE 
reporting the offhook event. If the suspend timer expires the Application Server can send a BYE request 
on the call-associated dialogue. 

• An SDP offer for a voice call. 

If a Session-Resume primitive is received, the Feature Manager shall request to the SIP UA to send an INVITE (off- 
hook) request built as follows: 

• The Request URI is structured as follows: 

A user part containing a unique value that signifies that a off-hook event was detected (such as 
offhook @pes-scc.operator.com) . 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile (see annex C). 

• A P-Asserted-Identity (AGCF) or a P-Preferred-Identity may be sent (VGW) containing the public identity of 
the subscriber on behalf of whom the off-hook event is reported. 

• An SDP offer for a voice call. 
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Annex C (informative): 

Implementation of Supplementary Services 

C.1 General principles 
C.1.1 Introduction 

This annex describes guiding principles for implementing commonly deployed PSTN supplementary services using the 
IMS-based PES architecture. The list of services is taken from EG 201 973-2 [i.6]. 

The actual service logic resides in the Application Server and is outside the scope of standardization. This annex 
focuses on the interactions between the AGCF and PES application servers. Only the part of the service logic which has 
an impact on signalling to/from the AGCF is described in this annex. 

Similar procedures may also be used in case of analogue lines connected to a VGW acting as a UE with regard to a 
P-CSCF in the PES. The present document will describe these procedures of the VGW in the appropriate clause. 

AGCF involvement in the execution of these services is limited to the generic capabilities described in the main body of 
the present document for supporting interworking between SIP and H.248 protocols and in annex B for processing 
flash-hook events. 

C.1 .2 Supplementary Service control 

This annex assumes that subscribers can control their supplementary services using service code commands and 
switching order commands as defined in ETS 300 738 [12]. 

More than one command can be dialled on a single call. For instance, a caller may dial the "inhibit call waiting" 
command, followed by the "calling line identity restriction" command, followed by the called party number. 

C.1 .2.1 Service code commands 

Service codes commands are user requests to perform an action that does not result in a call to another party. Actions 
such as feature activation, feature deactivation, and feature status inquiries are triggered by service code commands. 

C.1. 2. 1.1 Command syntax 

The format of service code commands as defined in ETS 300 738 [12] is reproduced below: 
"START PX SC (SR SI) SX" or "PX SC (SR SI) SX FINISH" 

Where: 

• START is the start command, e.g. "Off-hook", an alternative to the finish command; 

• PX is a mandatory service prefix; 

• SC is a mandatory service code; 

• SR is one or more separator/s, as required; 

• SI is one or more units of supplementary information, as required; 

• SX is a service suffix as required; 

• FINISH is a finish command, e.g. SEND, an alternative to the start command. 
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NOTE: Digit maps used by the media gateways or VGW to collect digits, include appropriate alternatives to cope 
with the syntax of service code commands. 

C.1 .2.1 .2 Generic procedure at the AGCF/VGW side 

On receipt of a service code command from a media gateway, the AGCF/VGW sends an INVITE request to the 
S-CSCF with the following information: 

• A Request-URI structured as follows: 

A user part containing the service code command, excluding the START and FINISH fields. 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile, e.g.: 

"PX SC (SR SI) SX"@pes-scc.operator.coin 

NOTE 1 : If the service code command includes a square "#" symbol, the userinfo portion of the Request-URI is in 
the form of a telephone-subscriber. The series of digits that form the service code command are encoded 
as a local-number. The phone-context attribute is set to a domain name of the PES operator, 
e.g. phonecontext=pes-scc. homedomain.com that is specific enough to enable the application server to 
interpret the commandecode. Setting the phone-context attribute is requked for conformance purposes 
with RFC 3966 [19]. PES network entities (e.g. CSCF) ignore this attribute. 

• An AGCF sends a P-Asserted-Identity header containing the pubhc user identity of the subscriber issuing the 
service code command or in the case of the VGW a P-Preferred-Identity header may be sent. If the 
P-Preferred-Identity is not sent then the PES Endpoint ensures that the From header contains the equivalent 
identity. 

• An SDP offer for a voice call. 

NOTE 2: The SDP offer may be used by the Application Server in case an announcement has to be delivered. 

0.1 .2.1 .3 Generic procedure at the AS side 

On receipt of the INVITE request that includes a service code command as Request-URI, the AS sends back a 183 
(Session Progress) message. 

NOTE: An SDP Answer may be included in the 183 (Session Progress) response in case the user is expected to 
key-in additional digits before the procedure can be completed. In such cases, the AS requests an 
MRFC/MRFP to play an appropriate prompting announcement and collect digits. The procedure for 
supporting user interactions during the call establishment phase is described within TS 124 628 [6]. 

If the procedure identified by the service code command is successfully performed, the AS modifies the subscriber 
profile according to the service code received, requests an MRFC/MRFP to play a positive acknowledgment tone or 
announcement and sends a 200 OK response towards the AGCF/VGW when the MRFC is connected. If the service 
code command corresponds to an interrogation procedure, the AS selects the appropriate announcement to notify the 
requested information (e.g. current supplementary service status) to the calling user. Release of the dialogue occurs 
when a BYE request is received from the MRFC or if a BYE/CANCEL request is received from the AGCF/VGW. 

If the procedure identified by the service code command cannot be performed successfully, the AS requests an 
MRFC/MRFP to play a negative acknowledgment tone or announcement and releases the call by sending a suitable 4xx 
or 5xx response to the INVITE request or by sending a BYE request if the dialogue is already established. The 
procedure for sending a tone or an announcement during the call establishment phase is described within 
TS 124 628 [6]. 
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C.1 .2.2 Switching order commands 



Switching order commands are typically used to invoke a service or modify the characteristics of a call, such as 
establish a three-party call. 

The format of switching order commands (SOC) is reproduced below: 

"START SO (SR SI)" or "SO (SR SI) FINISH" 

Where: 

START is a start command, e.g. "Register Recall (R)", an alternative to the finish command, as required; 

50 is a mandatory switching order; 
SR is one or more separators, as required; 

51 is one or more units of supplementary information, as required; 

FINISH is a finish command, e.g. "send", an alternative to the start command, as required. 

Processing of switching order commands where the start command is a Register Recall (also known as Flash-Hook 
event) is described in annex B. Processing of the Register Recall at the AGCFA'GW depends on the call configuration 
and loose or tight coupling methods (see clause B.4.2.2). 

Processing of the Register Recall at the VGW depends on the call configuration and usually the VGW delivers a dial 
tone and collect digits. 



C.1 .3 Setting of initial filter criteria 



Emulation of PSTN services requires that Initial Filter Criteria stored in the user profile be set on the following 
methods: 

• Originating INVITE methods. 

• Terminating INVITE methods. 

• Terminating MESSAGE methods. 

The user profile is selected based on the contents of the P-Asserted-Identity (originating method) or Request-URI 
(terminating method) headers. 

How many Initial Filter Criteria are actually required depend on how many application servers are involved in the 
provision of these services. 

When several application servers are involved, each implementing a particular service set or feature set, other service 
point triggers (SPT) may be added to Initial Filter Criteria so as to route the SIP messages to the appropriate server, in 
the right order. 

In case of outgoing calls (including special calls for service control purposes), the Request-URI may typically be part of 
an Initial Filter Criteria. The content tag will typically contain an Extended Regular Expressions (ERE) as defined in 
clause 9 in IEEE 1003.1-2004 [i.2] such that any Request-URI that includes a particular pattern (e.g. a domain name) 
matches the criteria. 

The following example illustrates the case of an IFC used to trigger an application server dedicated to the processing of 
service code commands, assuming that the AGCF/VGW appends the pes-scc.homedomain.com domain name to the 
service code commands. 

<InitialFilterCriteria> 

<Priority>0</Priority> 
<TriggerPoint> 

<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 
< Group > </ Group > 
<Method>INVITE</Method> 
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</SPT> 
<SPT> 

< Condi tionNegated>0< /Condi tionNegated> 
<Group>0</Group> 

<RequestURI>@pes-scc .homedomain. com$</RequestURI> 
</SPT> 
</TriggerPoint> 
<ApplicationServer> 

<ServerName>sip : PES-ASl@homedomain . com</ServerName> 
<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 

C.1 .4 Supplementary services using ISUP information 

Full support of supplementary services may be realized by exchanging service information between peer SIP signalling 
entities via SIP signalling and/or encapsulated ISUP information. The ISUP information necessary to support each 
individual service is specified by the corresponding ETSI or ITU-T supplementary service specification; see table C.l. 

Table C.I : Supplementary Service References 



Supplementary Service 


ETSI/ITU-T Reference 


Calling Line Identification Presentation (CLIP) 


EN 300 356-3 [34] 


Calling Line Identification Restriction (CLIR) 


EN 300 356-4 [34] 


Connected Line Identification Presentation (COLP) 


EN 300 356-5 [34] 


Connected Line Identification Restriction (COLR) 


EN 300 356-6 [34] 


Terminal Portability (IP) 


EN 300 356-7 [34] 


User-to-User Signalling (UUS) 


EN 300 356-8 [34] 


Closed User Group (CUG) 


EN 300 356-9 [34] 


Subaddressing (SUB) 


EN 300 356-10 [34] 


Malicious Call Identification (MCID) 


EN 300 356-11 [34] 


Conference Call (CONF) 


EN 300 356-12 [34] 


Explicit Call Transfer (ECT) 


EN 300 356-14 [34] 


Call Forwarding Busy (CFB) 


EN 300 356-15 [34] 


Call Forwarding No Reply (CFNR) 


EN 300 356-15 [34] 


Call Forwarding Unconditional (CFU) 


EN 300 356-15 [34] 


Call Deflection (CD) 


EN 300 356-15 [34] 


Call Hold (HOLD) 


EN 300 356-16 [34] 


Call Waiting (CW) 


EN 300 356-17 [34] 


Completion of Calls to Busy Subscriber (CCBS) 


EN 300 356-18 [34] 


Three-Party (3PTY) 


EN 300 356-19 [34] 


Completion of Calls on No Reply (CCNR) 


EN 300 356-20 [34] 


Anonymous Communication Rejection (ACR) 


EN 301 798 [39] 


Multi-Level Precedence and Pre-emption (MLPP) 


ITU-T Recommendation Q.735.3 [35] 


Global Virtual Network Service (GVNS) 


ITU-T Recommendation Q.735.6 [36] 


Reverse charging (REV) 


ITU-T Recommendation Q.736.3 [37] 



C.2 Advice of Charge 

C.2.1 Actions at the Originating AGCF 
C.2.1.1 General 

When receiving charging pulses from the Application Server (via the S-CSCF) the AGCF can either as a network 
option: 

• generate Metering Pulses by one of the methods described in clause C.2. 1 .2 and request the media gateway to 
generate metering pulses by means of one of the signals of the amet package defined in ITU-T 
Recommendation H. 248. 26 [14]; or 
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• build an Advice Of Charge message (see ES 200 659-3 [10]) by rules described in annex D and request the 
media gateway to transmit this message, using the Generic Data Signalling (data) signal of the Analogue 
Display Signalling (andisp) package defined in ITU-T Recommendation H. 248. 23 [13]. 

In addition to the procedures according to TS 124 229 [4], the Originating AGCF includes the Accept header field with: 

• "application/vnd.etsi.aocH-xml", the MIME type associated with AOC information (see annex E), and indicate 
the versions of the AOC XML Schema it supports. One of the versions - of the MIME type associated with 
AOC information (see annex E) - indicated corresponds with a value of the version attribute of the <schema> 
XML element of an AOC XML Schema (see annex E); and 

• any other MIME type the served UE is willing and capable to accept. 

C.2.1 .2 AGCF Metering Pulse generation 

C.2.1 .2.1 Usage of an AOC-D for Metering Pulse generation 

Upon receipt of an AOC- XML document including AOC-D information (i.e. with an "aocType" element set to 
"aoc-d"), the AGCF requests the media gateway to generate metering pulses using the Burst Pulses Count parameter of 
the Metering Pulse Burst signal of the amet package defined in ITU-T Recommendation H. 248.26 [14]. 
The Pulse Repetition Interval for metering burst is provisioned in the MG. 

C.2.1 .2.2 Usage of AOC-S for Metering Pulse generation 

Annex E extends the TS 124 647 [7] AOC -XML schema for Pulse Metering usage. This method may be used in order 
to reduce signalling load between AS and AGCF. It does not replace the actual billing information which is stored in 
CDRs of the responsible Application Servers. 

When receiving Pulse Metering Instructions from the PES Application Server (via the S-CSCF), the AGCF requests the 
media gateway to generate metering pulses by means of amet package defined in ITU-T Recommendation 

H.248.26 [14]. 

The type and duration of the pulses to be applied are provisioned in the MG. 

Procedures for Continuous Metering Pulse (Basic Communication continuous charge): 

Upon reception of AOC-S for basic communication with continuous type of charging (periodic metering), the AGCF 
requests the media gateway to generate metering pulses using the Pulse Count and Pulse Repetition Interval of the 
Enable Metering signal of the amet package defined in ITU-T Recommendation H.248.26 [14]. 

Procedures for single Metering Pulse Burst (e.g. for Communication Set-up charge, Service Add-on charge): 

Flat rate charging (e.g. at communication set-up or due to add-on charge) requires generation of a metering burst. 
The AGCF requests the media gateway to generate metering pulses using the Burst Pulses Count parameter of the 
Metering Pulse Burst signal of the amet package defined in ITU-T Recommendation H.248.26 [14]. The Pulse 
Repetition Interval for metering burst is provisioned in the MG. 

Procedures for Repetitive Metering Pulse Burst: 

The AGCF repetitively requests the media gateway every charging interval to generate metering pulses using the Burst 
Pulses Count parameter of the Metering Pulse Burst signal of the amet package defined in ITU-T Recommendation 
H.248.26 [14]. Alternatively, the AGCF may use a single H.248.26 [14] amet/phsm (phased metering) signal in order to 
request the media gateway to generate metering pulses, if this signal is supported. 

C.2.2 Actions at the Originating AS 
C.2.2.1 General 

Implementation of this service assumes that the AS providing the service is involved in all outgoing calls for which 
advice of charge information is expected. It is the responsibility of the network operator to configure the appropriate 
Initial Filter Criteria in the user profile. 
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Charging pulses or policies for generating charging pulses are transmitted from the Application Server to the AGCF 
using the method described in [7] when using the AOC-D Type. When using the AOC-S Type, the method defined in 
[7] requires to be extended per annex E. 

C.2.2.2 Usage of AOC-D for Metering Pulse generation 

The PES application server creates an XML document according to the schema defined in TS 124 647 [7], annex D 
including an "aoc" element with the following content: 

• The "aocType" element set to "aoc-d". 

• The "aoc-dType" element set to "recorded-charges". 

• The "recorded-chargesType" set to "recorded-currency-units". 

• The "currency-id-amountType" elements is set as follows: 

"currency-id" set to "UNIT"; 

"currency-amount" set to the number of additional charging units for the purpose pf metering pulses 
generation or to the accumulated charging units for the purpose of the AOC display service defined in 
ES 200 659-3 [10]. 

NOTE: This method requires the application server to be aware about the line type (for analogue line the AOC-D 
charging information is "additional", for ISDN line the AOC-D charging information is "accumulative"). 

C.2.2.3 Usage of AOC-S for Metering Pulse generation 
C.2.2.3.1 Overview of AOC-S usage with extended AOC 

Charging pulses or policies for generating charging pulses are transmitted from the Application Server to the 
VGW/AGCF using the following method: 

• The PES application server creates an XML document complying with the extended AOC XML schema 
defined in annex E. 

• The "aoc-extended" element may contain a "pes-transitioning behaviour" attribute element. 

The "pes-transitioning behaviour" parameter indicates to the VGW/AGCF how the transitioning behaviour on 
the line occurs. This is primarily related to the determination of pause durations among the last pulse of the 
previous tariff and the first pulse of the new tariff. 

• The "aocType" element set to "aoc-s". 

The "aoc-s" Type of the extended AOC XML schema is defined as a sequence of "aoc-s" metering phases. 
A sequence of "aoc-s" metering phases provides an entire call tariff in a single message from the AS to the 
VGW/AGCF. Each charging phase of a call is represented by an "aoc-s" metering phase. The duration of an 
"aoc-s" metering phase is defined by an "pes_aoc-s_phase_duration" parameter as part of the "charged-items" 
element. 

C.2.2.3.2 AOC Information Elements - Extensions to TS 1 24 647 - Annex C 

a) Pes-transitioning behaviour: 

The pes-transitioning behaviour is expressed as "immediate" or "continuous": 

Immediate: 

The new tariff becomes effective immediately as per the rules defined by the network operator. 
Typically, a still ongoing burst pulse train is finished or an individual pulse is completed and then the 
first pulse of the new tariff is generated at the least possible delay. 
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Continuous: 

Activating the new tariff takes account of the pauses between individual pulses or bursts of the new tariff 
and the time that has already elapsed since the last pulse of the previous tariff. The pause between the 
first pulse of the new tariff and the last pulse of the previous tariff is at least corresponding to the pause 
duration of the new tariff. 

The default "pes-transitioning behaviour" is "immediate". 

b) AOC-S PHASE Duration: 

Represents the duration of the "aoc-s" metering phase, in seconds. A value of "0" indicates an infinite duration. 

C.2.2.3.3 AOC-S Parameter settings for Pulse Metering generation 

For the purpose of Metering Pulse generation the AS uses the AOC XML described in annex E as follows: 

• The "currency-id" element has to be set to "UNIT". 

• The "currency-amount" element has to be set as follows: 

a) For periodic metering pulse generation the "currency-amount" value is set to "0". 

b) For metering burst pulse generation the "currency-amount" value is set to the number of pulses to be 
transmitted. 

• The "length- time- unit" element is used for Basic Communication price-time, continuous charging (periodic 
metering pulse or repetitive metering burst pulse). The currency-amount value determines the meaning of the 
"length- time- unit" element as follows: 

a) For "currency-amount"=0, the "length- time- unit" element is defined as the Pulse Repetition Interval. 
The Pulse Repetition Interval is defined as the interval from the leading edge of a metering pulse to the 
leading edge of the next metering pulse. 

b) For "currency-amount">l, the "length- time- unit" element is defined as the Charging Interval. The 
Charging Interval is defined as the interval at which the metering burst (consisting of N metering pulses) 
is repeated, in seconds. 

Metering Pulse Burst at start of call (AOC-S: Communication Set-Up - flat rate charging): 

The "aocType" element is set to "aoc-s". 

The optional "pes-transitioning-behaviourType" is specified, if required. 

The "aoc-sType" element is set to "charged-items". 

The optional "pes_aoc-s_phase_durationType" is expressed as a time unit in seconds, if required. 

The "charged-itemsType" is set to "communication-setup". 

The "communication-setupType" is set to "flat-rate". 

The "currency-id-amountType" elements is set as follows: 

"currency-id" set to "UNIT"; 

"currency-amount" set to the number of charging pulses. 
Periodic Metering Pulse (AOC-S: Basic Communication - price-time, continuous charging): 
The "aocType" element is set to "aoc-s". 

The optional "pes-transitioning-behaviourType" is specified, if required. 
The "aoc-sType" element is set to "charged-items". 
The optional "pes_aoc-s_phase_durationType" is expressed as a time unit in seconds, if required. 
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The "charged-itemsType" is set to "basic". 

The "basicType" is set to "price-time". 

The "price-timeType" elements is set as follows: 

"currency-id" set to "UNIT". 

"currency-amount" set to "0". 

"length- time- unit" set to Pulse Repetition Interval. 

"charging-type" set to "continuous". 
Periodic Metering Pulse Burst (AOC-S: Basic Communication - price-time, continuous charging): 
The "aocType" element is set to "aoc-s". 

The optional "pes-transitioning-behaviourType" is specified, if required. 
The "aoc-sType" element is set to "charged-items". 

The optional "pes_aoc-s_phase_durationType" is expressed as a time unit in seconds, if required. 
The "charged-itemsType" is set to "basic". 
The "basicType" is set to "price-time". 
The "price-timeType" elements is set as follows: 

"currency-id" set to "UNIT". 

"currency-amount" set to "N" (N>1) charging pulse. 

"length- time- unit" set to Charging Interval. 

"charging-type" set to "continuous". 
Metering Pulse Burst for Flat Rate charging (AOC-S: Basic Communication - flat rate charging): 
The "aocType" element is set to "aoc-s". 
The "aoc-sType" element is set to "charged-items". 
The "charged-itemsType" is set to "basic". 
The "basicType" is set to "flat-rate". 
The "currency-id-amountType" elements is set as follows: 

"currency-id" set to "UNIT". 

"currency-amount" set to N (N>1) charging pulses. 
Metering Pulse Burst for Add-On charging (AOC-S: Services- Flat-Rate): 
The "aocType" element is set to "aoc-s". 
The "aoc-sType" element is set to "charged-items". 
The "charged-itemsType" is set to "services". 
The "servicesType" is set to "flat-rate". 
The "currency-id-amountType" elements is set as follows: 

"currency-id" set to "UNIT". 

"currency-amount" set to the number of additional charging pulses. 
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Phase 1 = Metering Pulse Burst (start of call) and Phase 2= Periodic Metering Pulse: 

The "aocType" element is set to "aoc-s". 

The optional "pes-transitioning-behaviourType" is specified, if required. 
The "aoc-sType" consists of a sequence of two "aoc-s" phases as follows: 
1st "aoc-s" phase: 

The "aoc-sType" element is set to "charged-items". 

The "pes_aoc-s_phase_durationType" is expresses as a time unit in seconds. 

The "charged-itemsType" is set to "communication-setup". 

The "communication-setupType" is set to "flat-rate". 

The "currency-id-amountType" elements is set as follows: 
"currency-id" set to "UNIT". 

■ "currency-amount" set to the number of charging pulses. 
2nd "aoc-s" phase: 

The "aoc-sType" element is set to "charged-items". 
The "pes_aoc-s_phase_durationType" is set to "0" (infinite duration). 
The "charged-itemsType" is set to "basic". 
The "basicType" is set to "price-time". 
The "price-timeType" elements is set as follows: 
"currency-id" set to "UNIT". 

■ "currency-amount" set to "0". 

■ "length- time- unit" set to Pulse Repetition Interval. 

■ "charging-type" set to "continuous". 

Stopping generation of metering pulse (AOC-S: Basic Communication - free-charge): 
The "aocType" element is set to "aoc-s". 
The "aoc-sType" element is set to "charged-items". 
The "charged-itemsType" is set to "basic". 
The "basicType" is set to "free-charge". 

C.2.3 Actions at the Terminating AGCF 

Not applicable. 

C.2.4 Actions at the Terminating AS 

Not applicable. 
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C.2.5 Actions at the originating VGW 
C.2.5.1 General 

When receiving charging pulses from the AppHcation Server (via the S-CSCF) the VGW can either as a network 
option: 

• generate Metering Pulses by one of the methods described in clause C.2.5. 2; or 

• build an Advice Of Charge message (see ES 200 659-3 [10]) by rules described in annex D and transmit this 

message. 

In addition to the procedures according to TS 124 229 [4], the Originating VGW includes the Accept header field with: 

• "application/vnd.etsi.aoc+xml", the MIME type associated with AOC information (see annex E), and indicate 
the versions of the AOC XML Schema it supports. One of the versions - of the MIME type associated with 
AOC information (see annex E) - indicated is corresponding with a value of the version attribute of the 
<schema> XML element of an AOC XML Schema (see annex E); and 

• any other MIME type the served UE is willing and capable to accept. 

C.2.5. 2 VGW IVIetering Pulse generation 

C.2.5. 2.1 Usage of an AOC-D for Metering Pulse generation 

Upon receipt of an AOC- XML document including AOC-D information (i.e. with an "aocType" element set to 
"aoc-d"), the VGW generate metering pulses. The Pulse Repetition Interval for metering burst is provisioned in the 
VGW. 

C.2.5. 2. 2 Usage of AOC-S for Metering Pulse generation 

Annex E extends the TS 124 647 [7] AOC -XML schema for Pulse Metering usage. This method may be used in order 
to reduce signalling load between AS and VGW. It does not replace the actual billing information which is stored in 
CDRs of the responsible Application Servers. 

When receiving Pulse Metering Instructions from the PES Application Server (via the S-CSCF), the VGW generates 
metering pulses. 

The type and duration of the pulses to be applied are provisioned in the VGW. 

Procedures for Continuous Metering Pulse (Basic Communication continuous charge): 

Upon reception of AOC-S for basic communication with continuous type of charging (periodic metering), the VGW 
generates metering pulses using the Pulse Repetition Interval. The Pulse repetition interval is applied from the XML 
schema. 

Procedures for single Metering Pulse Burst (e.g. for Communication Set-up charge, Service Add-on charge): 

Flat rate charging (e.g. at communication set-up or due to add-on charge) requires generation of a metering burst. The 
Pulse Count is applied from the XML schema and the Pulse repetition interval is provisioned in the VGW. 

Procedures for Repetitive Metering Pulse Burst: 

The VGW repetitively generates single metering Burst Pulses. The burst repetition interval is applied from the XML 
schema. 

C.2.6 Actions at the terminating VGW 

Not apphcable. 
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C.3 Anonymous Call Rejection 
C.3.1 Actions at the Originating AGCF 

This service does not require the originating AGCF to perform any specific action. 

C.3.2 Actions at the Originating AS 

This service does not require the originating AS to perform any specific action. 

C.3. 3 Actions at the Terminating AS 

If the service is activated, the terminating AS rejects the call if the INVITE request includes the P-Asserted-Identity 
header field and includes the Privacy header field indicates "id", "header", or "user" as specified in RFC 3323 [24] and 
RFC 3325 [25]. In all other cases the communication proceeds normally. 

NOTE: If the P-Asserted-Identity header field is not present, the call is not rejected. 

When the AS rejects a communication, the AS sends an indication to the calling user by sending a 433 (Anonymity 
Disallowed) response. Additionally, before terminating the communication an announcement can be provided to the 
originating user. The procedure for invoking an announcement in the call establishment phase is described within 
TS 124 628 [6]. 

As a service option the ACR service may forward the communication to a voice message service instead of rejecting the 
communication with a 433 (Anonymity Disallowed) final response. 

C.3.4 Actions at the Terminating AGCF 

The terminating AGCF is not involved in the execution of this service. 

C.3.5 Actions at the Originating VGW 

This service does not require the originating VGW to perform any specific action. 

C.3.6 Actions at the Terminating VGW 

This service does not require the terminating VGW to perform any specific action. 



C.4 Automatic Call Return 

C.4.1 Actions at the AGCF at the invoker side 

The Automatic Call Return service is invoked using a service code command. On receipt of this service code command, 
the AGCF builds an INVITE request as described in clause C. 1 . 

C.4. 2 Actions at the AS at the invoker side 

Implementation of this service assumes that the AS providing the service is involved in all incoming calls to the served 
user. It is the responsibility of the network operator to configure the appropriate Initial Filter Criteria in the user profile. 
The AS keeps track of the most recent incoming call to each served user it manages. 
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When receiving the service code command that identifies the Automatic Call Return service, the AS acts as a B2BUA 
and establishes a new call leg to the most recent caller (i.e. it sends an INVITE messages towards this most recent call 
party as if the number had been dialled by the served user), unless presentation of the corresponding identity was 
restricted or this identity was not available. 

C.4.3 Actions at the VGW at the invoker side 

The Automatic Call Return service is invoked using a service code command. On receipt of this service code command, 
the VGW builds an INVITE request as described in clause C.l. 



C.5 Calling Line Identity Presentation/Restriction 
C.5.1 Actions at the Originating AGCF 

A service code command may be received by the AGCF in case the calling user wishes to override the default setting 
for a particular call, in which case the called party number is embedded in the command code as part of the 
supplementary information. The AGCF generates an INVITE request according to the rules described in clause C. 1 . 

Otherwise the originating AGCF is not involved in the provision of this service. 



C.5. 2 Actions at the Originating AS 



The AS determines whether calling identification is presented or restricted based on user profile data (permanent mode) 
or based on the contents of the Request-URI (per-call mode). 

Any service prefix is removed from the Request-URI before forwarding the INVITE request toward the called party. 

If calling identification restriction is in force, the AS applies the following changes before forwarding the received 
INVITE request towards the called party via the S-CSCF: 

• Override the contents of the From header field with an "anonymous" indication. The convention for 
configuring an anonymous From header field described in RFC 3323 [24] and RFC 3325 [25] should be 
followed; i.e.: 

From: "Anonymous" <sip:anonymous ©anonymous. invalid>;tag= xxxxxxx. 

• Include a Privacy header field set to "id" and optionally "header" or/and "user" in accordance with 
RFC 3323 [24] and RFC 3325 [25]. 

If the originating user wishes to override the default setting of "presentation restricted" of the OIR service in temporary 
mode, the originating AS includes a Privacy header field of privacy type "none" in accordance with 
TS 124 229 [4] and RFC 3323 [24]. 

On receipt of an INVITE request with a service code command requesting that the calling line identity be presented to 
the called party, the AS removes the service prefix from the service code command and forwards the INVITE request 
unchanged towards the called party, via the S-CSCF. 

Otherwise the originating AS is not involved in the provision of this service. 



C.5. 3 Actions at the Terminating AS 



If the service is subscription dependent and the called user has not subscribed to the service, the terminating AS 
removes any P-Asserted-Identity and Privacy header fields included in the request. Additionally, the Application Server 
may as a network option set the contents of the From header to a default non significant value which is different from 
the values in the list below: 

• From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag= xxxxxxx. 
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• From: "Unavailable" <"sip:unavailable@unknown.invalid>;tag= xxxxxxx. 

The following From header value is recommended in order to indicate that the subscriber has not subscribed: 

• From: "Unsubscribed" <sip:unsubscribed@unsubscribed.invalid>;tag= xxxxxxx. 

If the request includes the Privacy header field set to "header" the AS set the contents of all headers containing private 
information in accordance with RFC 3323 [24] and RFC 3325 [25]. 

If the request includes the Privacy header field set to "user" the AS removes or set the contents of all "user 
configurable" headers in accordance with RFC 3323 [24] and RFC 3325 [25]. In the latter case, the AS may need to act 
as transparent back-to-back user agent as described in RFC 3323 [24]. 

NOTE: If the request includes the Privacy header field set to "id", the P-Asserted-Identity header is removed by 
the S-CSCF. 

C.5.4 Actions at the Terminating AGCF 

User Identification information received in an INVITE request ("P-Asserted-Id", "Privacy", and "From" headers) is 
used by the AGCF to generate the appropriate Call Setup message (see ES 200 659-3 [10]) to be delivered to the called 
terminal, using the H.248 andisp package. Generation of the Call Setup message is further described in annex D. 



C.5.5 Actions at the Originating VGW 

A service code command may be received by the VGW in case the calling user wishes to override the default setting for 
a particular call, in which case the called party number is embedded in the command code as part of the supplementary 
information. The VGW generates an INVITE request according to the rules described in clause C. 1 . 

Otherwise the originating VGW is not involved in the provision of this service. 

C.5.6 Actions at the Terminating VGW 

User Identification information received in an INVITE request ("P-Asserted-Id", "Privacy", and "From" headers) is 
used by the VGW to generate the appropriate Call Setup message (see ES 200 659-3 [10]) to be delivered to the called 
terminal. Generation of the Call Setup message is further described in annex D. 



C.6 Calling Name Delivery 
C.6.1 Actions at the Originating AGCF 

No specific action is performed by the AGCF. 

C.6.2 Actions at the Originating Application Server 

If the calling user has subscribed to the service and no presentation restriction is invoked, the originating AS inserts a 
pre-configured calling name in the Display field of the From header and possibly the same or different name in the 
Display field of the P-Asserted-Identity header. 

C.6.3 Actions at the Terminating Application Server 

If the service is subscription dependent and the called user has not subscribed to the service, the terminating AS 
removes or the From header or set its contents in accordance with RFC 3323 [24]. 

If the request includes the Privacy header field set to "header" the AS sets the contents of all headers containing private 
information in accordance with RFC 3323 [24] and RFC 3325 [25]. 
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If the request includes the Privacy header field set to "user" the AS removes or sets the contents of all "user 
configurable" headers in accordance with RFC 3323 [24] and RFC 3325 [25]. In the latter case, the AS may need to act 
as transparent back-to-back user agent as described in RFC 3323 [24]. 

C.6.4 Actions at the Terminating AGCF 

User Name information received in an INVITE request ("From" header /or "P-Asserted-Identity") is used by the AGCF 
to generate the appropriate Call Setup message (see ES 200 659-3 [10]) to be delivered to the called terminal, using the 
H.248 andisp package. Generation of the Call Setup message is further described in annex D. 

C.6.5 Actions at the Originating VGW 

This service does not require the originating VGW to perform any specific action. 

C.6.6 Actions at the Terminating VGW 

User Name information received in an INVITE request ("From" header /or "P-Asserted-Identity") is used by the VGW 
to generate the appropriate Call Setup message (see ES 200 659-3 [10]). Generation of the Call Setup message is further 
described in annex D. 



C.7 Call Forwarding 

C.7.1 Activation/Deactivation/lnterrogation 
C. 7.1.1 Actions at the AGCF 

Registration, Erasure, Activation, Deactivation and Interrogation of call forwarding services is performed using service 
code commands as described in ETS 300 738 [12]. 

On receipt of a service code command that corresponds to one of these procedures, the AGCF proceeds as described in 
clause C.l. 

C.7. 1.2 Actions at the AS 

On receipt of a service code command, the AS proceeds as described in clause C. 1 . 

In case of unconditional call forwarding the AS may also send a NOTIFY request to the AGCF/VGW to update the Dial 
Tone Management XML document. 

C.7. 1.3 Actions at the VGW 

Registration, Erasure, Activation, Deactivation and Interrogation of call forwarding services is performed using service 
code commands as described in ETS 300 738 [12]. 

On receipt of a service code command that corresponds to one of these procedures, the VGW proceeds as described in 
clause C.l. 



C.7. 2 Invocation 

C. 7.2.1 Actions at the Originating AGCF 

No specific action is performed by the AGCF. 
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C. 7.2.2 Actions at the Originating AS 

No specific action is performed by the AS. 

C. 7.2.3 Actions at tlie Forwarding AS 

The AS implements procedures identical or similar to those described in TS 124 604 [9]. 

C. 7.2.4 Actions at tine Forwarding AGCF 

The AGCF at the forwarding side is not involved in the processing of forwarded calls. 

C.7.2.5 Actions at tine Terminating AS 

No specific action is performed by the AS. 

C. 7.2.6 Actions at the Terminating AGCF 

Call forwarding information received in an INVITE request ("history-info" header) is used by the AGCF to generate the 
appropriate Call Setup message (see ES 200 659-3 [10]) to be delivered to the called terminal, using the H.248 andisp 
package. Generation of the Call Setup message is further described in annex D. 

C. 7.2.7 Actions at the Originating VGW 

No specific action is performed by the VGW. 

C. 7.2.8 Actions at the Forwarding VGW 

The VGW at the forwarding side is not involved in the processing of forwarded calls. 

C. 7.2.9 Actions at the Terminating VGW 

Call forwarding information received in an INVITE request ("history-info" header) is used by the VGW to generate the 
appropriate Call Setup message (see ES 200 659-3 [10]) Generation of the Call Setup message is further described in 
annex D. 

C.8 Distinctive Ringing 

0.8.1 Actions at the Originating AGOF 

This service does not require the originating AGCF to perform any specific action. 

0.8.2 Actions at the Originating Application Server 

This service does not require the originating AS to perform any specific action. 

0.8.3 Actions at the Terminating Application Server 

The terminating AS inserts an "alert-info" header field in the INVITE request with a value selected based on the value 
of the P-Asserted-Identity header field received in the incoming INVITE request and on the called user profile. 
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NOTE: The content of "alert-info" header field has to be agreed between the AS and the AGCF / VGW. A 
suggested default template for encoding the "alert-info" header field value is Alert-Info: 
<http://localhost/pattern_N>, where pattern_N is associated to a specific ring pattern. 

C.8.4 Actions at the Terminating AGCF 

The terminating AGCF uses the value of the "alert-info" header to select the appropriate ring pattern. The pattern 
identifier is sent to the media gateway as a parameter of the H.248 andisp/dwa signal. 

C.8.5 Actions at the Originating VGW 

This service does not require the originating VGW to perform any specific action. 

C.8.6 Actions at the Terminating VGW 

The terminating VGW uses the value of the "alert-info" header to select the appropriate ring pattern. 

C.9 Call Waiting 

C.9.1 General for Loose Coupling 

C.9.1 .1 Actions at the AGCF at the terminating side 

• On receipt of an INVITE request for a busy subscriber, the AGCF determines whether to trigger a call waiting 
procedure as specified in clause 7.3.1.3.2. 

If the call waiting timer expires the AGCF sends a 486 (Busy Here) or 480 (Temporarily unavailable) response towards 
the Application Server, depending on the operator policy. 

As an option, the calling user may be specifically informed that the called user has not answered the communication if a 
Reason header field set to cause 19 (no answer from user, user alerted) is included in the 480 (Temporarily unavailable) 
response. 

If a flash-hook event is reported by the media gateway, the AGCF stops the call-waiting timer and requests the media 
gateway to perform the following actions unless an explicit indication that the HOLD service is not provisioned to the 
user has been previously received as part of the profile delivery procedure: 

• Set the stream mode of the ephemeral termination to inactive. 

• Apply a dial tone. 

• Collect a switching order command. 

NOTE 1 : In some networks, applying a dial tone and collecting an explicit switching order command is not 

required as the register recall is interpreted as a request to accept the waiting call. Subsequent AGCF 
procedures are executed as if an equivalent switching order command had been received from the user. 

The number of digits is provisioned in the AGCF. The AGCF also sends a re-INVITE request on the initial dialogue to 
hold the associated media stream, as described in TS 124 610 [8]. 

Processing of the switching order command depends on whether loose or tight coupling procedures are applied between 
the AGCF and the AS. Figure C.l illustrates the loose coupling case while figure C.2 illustrates the tight-coupling case. 

NOTE 2: These figures do not take into account all possible service code commands that may be received from the 
user (e.g. service code command requesting that a waiting call be accepted and the active call be 
released). 
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The AGCF evaluates the Switch Order Command based on a provisioned mapping table. 

If the SOC indicates that the served user wishes to be connected to the waiting party, the AGCF performs the following 
actions: 

• Send a 200 OK response to the INVITE request received from the waiting party. 

• Request the media gateway to: 

Modify the Remote Descriptor of the ephemeral termination according to the SDP information received 
from the waiting party. 

Monitor the flash-hook event. 

If SOC indicates that the served user wishes to reject the waiting call, the AGCF performs the following actions: 

• Send a provisioned error response code (e.g. 603) to the INVITE request received from the waiting party. 

• Request the media gateway to: 

Set the stream mode to send-receive. 
Monitor the flash-hook event. 

• Send a re-INVITE request towards the held party (i.e. the party that has been held for the purpose of collecting 
the switching order command). The re-INVITE request is built as follows: 

The Request-URI is set to the held party's identity. 

The SDP description for the active media stream is set to a=sendrecv. 

Once the communication is established with the waiting party, the user may decide to switch back to the initial party, 
using a Register Recall followed by new switching order command. If the value of the switching order command 
indicates that the initial party is switched back, the AGCF performs the following actions: 

• Send a re-INVITE request towards the held party. The re-INVITE request is built as follows: 

The Request-URI is set to the held party's identity. 

The SDP description for the active media stream is set to a=sendrecv. 

• Send a re-INVITE request towards the active party. The re-INVITE request is built as follows: 

The Request URI is set to the active party's identity. 

The SDP description for the active media stream is set to a=sendonly. 

• Request the media gateway to: 

Modify the Remote Descriptor of the ephemeral termination according to the SDP information associated 
with the held party. 

Monitor the flash-hook event. 

If the feature code received from the internal MGC component does not match any known feature, the AGCF ignores 
the feature code and optionally requests the media gateway to play an error tone or an announcement to the served user. 

C.9.1 .2 Actions at the AS at the terminating side 

Implementation of this service assumes that the AS providing the service is involved in all calls to/from the subscriber. 

Based on network operator option the AS determines whether the called user is busy. See note. 

If the option is not used then the AGCF/VGW determines the busy condition of the terminating party. 

If the called user is busy and has not subscribed to the call waiting service, the AS sends a 486 (Busy Here) response 
towards the calling party. 
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If the called user is busy and has subscribed to the call waiting service, the AS builds an INVITE request using normal 
rules as for any incoming call. 

NOTE: Information for the handling of NDUB can be found in TS 124 628 [6], clause B.2. 

If the AS applies a "call is a waiting call announcement" in addition to the Alert-Info header field set to 
'urn:alert:service:call-waiting' in the 180 Ringing sent towards the caller's PES Access point the AS includes the 
P-Early-Media header as described in clause 5.3.3.3. 

On receipt of a re-INVITE request with a SDP "sendonly" attribute, the AS interacts with an MRFC is order to play an 
announcement to the held party, in accordance with TS 124 628 [6]. 

On receipt of a re-INVITE request with the SDP attribute "sendrecv", the AS interacts with the MRFC to stop any 
ongoing announcement. 



£75/ 



99 



ETSI TS 183 043 V3.4.1 (2011-04) 



AS 



AGCF 



1. INVITE (D2, SDP 
offer from C) 



MGF 



TE 



2. H.248 interaction to apply Call Waiting 
toneand monitor flash-hook events 



3a 180 Ringing 

(D2, Alert-Info: 

-urn:alert:service: 

call-waiting) 



4a. the AS has the possibility to 

generate a CW announcement. In 

this case the P-early-media header 

has to be added to the 180 Ringing 

response 



7. Re-INVITE 

- (D1, SDP - 

a=sendonly) 



9. Interaction with 

held party (B) e.G 

announcement 



3. CWTone — 

»4. Register Recall 



5. Flash hook 
detected 



-6. NOTIFY- 



8. H.248 Stream Mode Set 
inactive 



10. H.248 interaction to apply 
dial tone and collect digits 



-11. Dialtone 
-12. Digits- 



13. Digits detected 



14. NOTIFY- 



15 evaluate Switch 
order code 



-16. 200 OK (D2)- 



17 H.248 Remote 
Descriptor set to SDP-C 



-«18. 603 Decline (D2)- 

19. Re-INVITE 

— (D1,SDP 

a=sendrecv) 



20a 

announ 



Stop 
cement 



20 H.248 Stream Mode set 
to send&receive 



Figure C.1 : Call Waiting with loose AGCF/ AS coupling 

C.9.1 .3 Actions at the VGW at the terminating side 

On receipt of an INVITE request for a busy subscriber, the VGW determines whether to trigger a call waiting procedure 
as specified in clause 7.3.1.3.2 for an AGCF. 

If a call waiting procedure is to be invoked, the VGW proceeds as follows: 

• Apply call waiting tone. 

• Monitor flash-hook events. 
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• Send a 180 (Alerting) including an Alert-Info header field set to "urn:service:call-waiting" towards the AS. 

• Start a call-waiting timer. 

If the call-waiting timer expires then dependant on network operator policy the VGW sends a 486 (Busy Here) or 480 
(Temporarily unavailable) response towards the Application Server. 

As an option, the calling user could be specifically informed that the called user has not answered the communication if 
a Reason header field set to cause 19 (no answer from user, user alerted) is included in the 480 (Temporarily 
unavailable) response. 

If a flash-hook event is received by the VGW it stops the no-answer timer and requests the media gateway to perform 
the following actions unless an explicit indication that the HOLD service is not provisioned to the user has been 
previously received as part of the profile delivery procedure: 

• Set the stream mode of the IP media termination to inactive. 

• Apply a dial tone. 

• Collect a switching order command. 

NOTE 1 : In some networks, applying a dial tone and collecting an explicit switching order command is not 

required as the register recall is interpreted as a request to accept the waiting call. Subsequent VGW 
procedures are executed as if an equivalent switching order command had been received from the user. 

The number of digits is provisioned in the VGW. The VGW also sends a re-INVITE request on the initial dialogue to 
hold the associated media stream, as described in TS 124 610 [8]. 

Processing of the switching order command depends on whether loose or tight coupling procedures are applied between 
the VGW and the AS. Figure C.l illustrates the loose coupling case while figure C.2 illustrates the tight-coupling case. 

NOTE 2: These figures do not take into account all possible service code commands that may be received from the 
user (e.g. service code command requesting that a waiting call be accepted and the active call be 
released). 

The VGW evaluates the Switch Order Command based on a provisioned mapping table. 

If the SOC indicates that the served user wishes to be connected to the waiting party, the VGW performs the following 
actions: 

• Send a 200 OK response to the INVITE request received from the waiting party. 

• The VGW procedures are: 

Modify the IP media termination according to the SDP information received from the waiting party. 
Monitor the flash-hook event. 
If SOC indicates that the served user wishes to reject the waiting call, the VGW performs the following actions: 

• Send a provisioned error response code (e.g. 603) to the INVITE request received from the waiting party. 

• The VGW. 

Set the stream mode of the IP media termination to send-receive. 
Monitor the flash-hook event. 

• Send a re-INVITE request towards the held party (i.e. the party that has been held for the purpose of collecting 
the switching order command). The re-INVITE request is built as follows: 

The Request-URI is set to the held party's identity. 

The SDP description for the active media stream is set to a=sendrecv. 
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Once the communication is established with the waiting party, the user may decide to switch back to the initial party, 
using a Register Recall followed by new switching order command. If the value of the switching order command 
indicates that the initial party is switched back, the VGW performs the following actions: 

• Send a re-INVITE request towards the held party. The re-INVITE request is built as follows: 

The Request-URI is set to the held party's identity. 

The SDP description for the active media stream is set to a=sendrecv. 

• Send a re-INVITE request towards the active party. The re-INVITE request is built as follows: 

The Request URI is set to the active party's identity. 

The SDP description for the active media stream is set to a=sendonly. 

• The VGW: 

Modify the IP media termination according to the SDP information associated with the held party. 

Monitor the flash-hook event. 

If the feature code received does not match any known feature, the VGW ignores the feature code and optionally play 
an error tone or an announcement to the served user. 
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Figure C.1 A: Call Waiting with loose VGW coupling 

C.9.2 Void 
C.9.2.1 Void 
C.9.2.2 Void 

C.9.3 General for Tigiit coupling 

C.9.3.1 Actions at the AGCF at the terminating side 

On receipt of an INVITE D2 request for a busy subscriber, the AGCF determines whether to trigger a call waiting 
procedure as specified in clause 7.3.1.3.2. 
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If a flash-hook event is reported by the media gateway as shown in figure C.IB, the AGCF requests the media gateway 
to set the stream mode of the ephemeral termination to inactive. 

The AGCF sends an INVITE (flash) on dialogue D4 to the AS and await receipt of 200 OK (Invite) and when this is 
received it sends an ACK. The AGCF then sends a 200 OK (Invite) on dialogue D2 and await receipt of the ACK. 

The AGCF then awaits receipt of a Re-INVITE on dialogue D2, (which allows re-negotiation of the SDP between user 
A/B and user C) responds with a 200 OK (Invite) and awaits receipt of an ACK and a BYE (D4). On receipt of this 
BYE it sends a 200 OK (Bye). 

C.9.3.2 Actions at the AS at the terminating side 

Implementation of this service assumes that the AS providing the service is involved in all calls to/from the subscriber. 

The AS determines the busy condition of the called user based on the procedures described in TS 124 628 [6]. 

If the called user is busy and has not subscribed to the call waiting service, the AS sends a 486 (Busy Here) response 
towards the calling party. 

NOTE 1 : The procedures for NDUB are out of scope of the specification of CW procedures. Information for the 
handling of NDUB can be found in TS 124 628 [6], clause B.2. 

If the called user is approaching 'ndbu' and has subscribed to the call waiting service, the AS builds an INVITE D2 
request using normal rules as for any incoming call. The INVITE request may include as a network operator option a 
CW MIME body, in compHance with TS 124 615 [44]. 

On receipt of a 180 (Ringing) response, the AS inserts an Alert-Info header field set to "urn:service:call-waiting" into 
the 180 and interacts with an MRFC in order to play an announcement to the calling party, and starts a timer (which is 
stopped on receipt of an INVITE (flash)) to determine the overall call waiting service period (if the CW timer expires, 
the AS sends a CANCEL (D2) to the AGCF/VGW). 

When (if) an INVITE (flash) (D4) is received the AS sends a 200 OK response (as this is Simplified Call Waiting) and 
await receipt of the ACK. 

The AS awaits receipt of a 200 OK (Invite) on dialogue D2, and respond with an ACK. The AS then re-arranges the 
bearers to connect the calling party (C) to the called party (A/B) by sending a Re-INVITE (D2) with no SDP to the 
AGCF/VGW. It then awaits receipt of the 200 OK (Invite) containing the SDP of the A/B party and when received it 
sends an ACK to the AGCF/VGW containing the SDP of the C party. 

The AS can also arrange for an announcement to be played to the held party (B/A) via an MRFC/MRFP and arranges 
for a BYE (D4) to be sent to the AGCF/VGW. 

The call flow for this service (when accepting the waiting call with a RECALL) is shown in figure C.IB and is 
described in the previous paragraphs of this clause. The call flow for this service (when accepting the waiting call by 
going ON HOOK) is shown in figure C.IB. 
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NOTE: Not all messages (like 100 Trying) and Preconditions "which may be optionally included are shown in the 
flow". 

Figure C.1C: Called Customer goes ON HOOK 

NOTE 2: A no answer timer on the AGCF/VGW to remove the dependence of the AGCF/VGW network on the AS 
network may be defined in a future Release. 

Figure C.2: Void 

C.9.3.3 Actions at the VGW at the terminating side 

On receipt of an INVITE D2 request for a busy subscriber the VGW determines whether to trigger a call waiting 
procedure as specified in clause 7.3.1.3.2. If a call waiting procedure is to be triggered, the VGW performs the 
following actions: 

• Apply call waiting tone. 

• Monitor flash-hook events. 
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• Send a 180 (Ringing) towards the AS. 

If a flash-hook event is reported as shown in figure C.IB, the VGW sets the IP media termination to inactive. 

The VGW sends an INVITE (flash) on dialogue D4 to the AS and await receipt of 200 OK (Invite) and when this is 
received it sends an ACK. The VGW then sends a 200 OK (Invite) on dialogue D2 and await receipt of the ACK. 

The VGW then awaits receipt of a Re-INVITE on dialogue D2, (which allows re-negotiation of the SDP between user 
A/B and user C) responds with a 200 OK (Invite) and awaits receipt of an ACK and a BYE (D4). On receipt of this 
BYE it sends a 200 OK (Bye). 
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Figure C.2A: Call Waiting with tight VGW coupling 
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C.10 Incoming Call Barring 

C.1 0.1 Activation/Deactivation/lnterrogation 
C.10. 1.1 Actions at the AGCF 

Activation, deactivation and interrogation of incoming call barring is performed using service code commands as 
described in ETS 300 738 [12]. On receipt of a service code command, the AGCF sends an INVITE request as 
described in clause C.l. 

C.10.1.2 Actions at the AS 

On receipt of the INVITE request that includes a service code command as Request-URI, the AS proceeds as described 
in clause C.l. 

C. 1 0. 1 .3 Actions at the VGW 

Activation, deactivation and interrogation of incoming call barring is performed using service code commands as 
described in ETS 300 738 [12]. On receipt of a service code command, the AGCF sends an INVITE request as 
described in clause C.l. 

C.l 0.2 Invocation 

C.l 0.2.1 Actions at the Originating AGCF 

The originating AGCF is not involved in the invocation of the service. 

C.l 0.2.2 Actions at the Originating AS 

The originating AGCF is not involved in the invocation of the service. 

C.l 0.2.3 Actions at the Terminating AS 

On receipt of an INVITE request from a calling user, if incoming call barring is activated, the AS checks the 
P-Asserted-Identity against the list of allowed/forbidden calling parties. The rules and information used by the AS to 
evaluate whether the call is accepted are operator dependent. They may be compatible subset of the rules described in 
TS 124 611 [27]. 

If the call is rejected, the AS notifies the calling user by sending a 603 (Decline) response. Additionally, before 
terminating the communication an announcement can be provided to the originating user. The procedure for invoking 
an announcement in the call establishment phase is described within TS 124 628 [6]. 

C.l 0.2.4 Actions at the Terminating AGCF 

The terminating AGCF is not involved in the provision of the service. 

C.l 0.2.5 Actions at the Originating VGW 

The originating VGW is not involved in the invocation of the service. 

C.l 0.2.6 Actions at the Terminating VGW 

The terminating VGW is not involved in the provision of the service. 
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C.1 1 Malicious Call Identification (Loose coupling) 
C.1 1 .1 Actions at the Originating AGCF 

The AGCF at the originating side is not involved in the provision of this service. 

C.1 1.2 Actions at the Originating AS 

The AS at the originating side is not involved in the provision of this service. 



C.1 1.3 Actions at the Terminating AS 

Support of the Malicious Call Identification (MCID) service requires that the AS providing the service is involved in all 
incoming calls to the served user. 

The AS registers the details of the last incoming call in a special record upon reception of either: 

• A re-INVITE request with a Request-URI set to the served user's identity and a MCID XML document with an 
McidRequestlndicator set to 1 . 

• A re-INVITE request with a Request-URI set to the served user's identity without any message body. 

In the later case, other services that could use the re-INVITE not containing any message body as service invocation is 
disabled. 

Processing of this record is outside the scope of standardization. 

C.1 1 .4 Actions at the Terminating AGCF 

The AGCF detects invocation of MCID and generates a re-INVITE request as described in clause B.4.2.2.2. 

As a network option, the AGCF may use the annex A Profile Delivery mechanism for obtaining the subscriber MCID 
subscription status (provisioned/withdrawn). 

C.1 1 .5 Actions at the Originating VGW 

The VGW at the originating side is not involved in the provision of this service. 

C.1 1 .6 Actions at the Terminating VGW 

The VGW detects invocation of MCID and generates a re-INVITE request as described in clause B.4.2.2.2. 

As a network option, the VGW may use the annex A Profile Delivery mechanism for obtaining the subscriber MCID 
subscription status (provisioned/withdrawn). 

0.11 A Malicious Call Identification (Tight coupling) 
C.1 1 A.I Actions at the Originating AGCF 

The AGCF at the originating side is not involved in the provision of this service. 
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C.11 A.2 Actions at the Originating AS 

The AS at the originating side is not involved in the provision of this service. 

C.11 A.3 Actions at the Terminating AS 

Support of the MaHcious Call Identification (MCID) service requires that the AS providing the service is involved in all 
incoming calls to the served user. 

On receipt of an INVITE request containing a Request-URI representing a flash hook event (e.g. flash @pes 
scc.operator.com), the AS may either, as a network option: 

• Interpret the INVITE request as a request for invocation of the MCID service, in which case other services 
using flash-hook as means for invocation are disabled for this terminating user. 

• Instruct another entity under its control such as a Media Resource Function to perform digit collection as 
described in annex G. Alternatively it may instruct the AGCF/VGW to collect a special service code. 

NOTE: The AS procedure for requesting an AGCF/VGW to collect digits is for further study. 

When the AS has sufficient information to determine that invocation of the MCID service is requested, the AS registers 
the details of the last incoming call in a special record. Processing of this record is outside the scope of standardization. 

C.1 1 A.4 Actions at the Terminating AGCF 

The MCID service is invoked during the active phase of the communication or after the active phase for a limited 
period, using either Register Recall or a Register Recall followed by a special service code. 

On receipt of a flash-hook event, the AGCF sends an INVITE request to the AS as specified in clause B.4.2.2.3. 

NOTE: As a network option, the AGCF may be instructed by the AS to collect a special service code. 

C.1 1 A.5 Actions at the Originating VGW 

The VGW at the originating side is not involved in the provision of this service. 

C.1 1 A.6 Actions at the Terminating VGW 

The MCID service is invoked during the active phase of the communication or after the active phase for a limited 
period, using either Register Recall or a Register Recall followed by a special service code. 

On receipt of a flash-hook event, the VGW sends an INVITE request to the AS as specified in clause B.4.2.2.3. 

NOTE: As a network option, the VGW may be instructed by the AS to collect a special service code. 



0.12 IVIessage Waiting Indicator 
C.I 2.1 Actions at the AGCF 

On receipt of a NOTIFY request reporting the "message-summary" event, the AGCF requests the following actions 
from the media gateway: 

• Modify the default dial tone. 

• Send a Message Waiting Indicator message (see ES 200 659-3 [10]) using the H.248 andisp/data signal. 
Generation of the Message Waiting Indicator message by the AGCF is described in annex D. 
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C.12.2 Actions at the AS 

The AS implements the procedures described in TS 124 606 [26]. 

C.12.3 Actions at the VGW 

On receipt of a NOTIFY request reporting the "message-summary" event, the VGW: 

• Modify the default dial tone. 
Send a Message Waiting Indicator message (see ES 200 659-3 [10]). 
Generation of the Message Waiting Indicator message by the VGW is described in annex D. 

C.13 Outgoing Call Barring 

C.13.1 Activation/Deactivation/lnterrogation 
C.13. 1.1 Actions at the AGCF 

Activation and deactivation of outgoing call barring is performed using service code commands as described in 
ETS 300 738 [12]. On receipt of a service code command, the AGCF sends an INVITE request as described in 
clause C.l. 

C.13.1.2 Actions at the AS 

On receipt of the INVITE request that includes a service code command as Request-URI, the AS proceeds as described 
in clause C.l. 

C. 1 3. 1 .3 Actions at the VGW 

Activation and deactivation of outgoing call barring is performed using service code commands as described in 
ETS 300 738 [12]. On receipt of a service code command, the VGW sends an INVITE request as described in 
clause C.l. 

C.l 3.2 Invocation 

C.l 3.2.1 Actions at the Originating AGCF 

The originating AGCF is not involved in the invocation of the service. 

C.l 3.2.2 Actions at the Originating AS 

On receipt of an INVITE request from a calling user, if outgoing call barring is activated, the AS checks the 
Request-URI against the list of allowed/forbidden called destinations. The rules and information used by the AS to 
evaluate whether the call is accepted are operator dependent. They may be compatible subset of the rules described in 
TS 124 611 [27]. 

If the call is rejected, the AS notifies the calling user by sending a 603 (Decline) response. Additionally, before 
terminating the communication an announcement can be provided to the originating user. The procedure for invoking 
an announcement in the call establishment phase is described within TS 124 628 [6]. 
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C. 13.2.3 Actions at the Terminating AS 

The terminating AS is not involved in the provision of the service. 

C. 1 3.2.4 Actions at tlie Terminating AGCF 

The terminating AGCF is not involved in the provision of the service. 

C. 13.2.5 Actions at tlie Originating VGW 

The originating VGW is not involved in the invocation of the service. 

C.I 3.2.6 Actions at tine Terminating VGW 

The terminating VGW is not involved in the provision of the service. 



C.14 Three Party Service 
C.I 4.0 General 

Processing of the switching order command depends on whether loose or tight coupling procedures are applied between 
the AGCF and the AS. Moreover, in loose coupling case, two methods can be used: the INVITE method, described in 
clause C.14.2, and the REFER method, described in clause C.14.2A. Figure C.4 illustrates the loose coupling case with 
the INVITE method while figure C.5 illustrates the loose coupling case with the REFER method. The tight coupling 
case is described in clause C.14.3. 

For the transport of dialled digits identifying the third party to be called Overlap Signalling may apply. If Overlap 
Signalling is supported between the AGCFA'GW and the Application Server at the originating side the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annex F is 
dependent on national or network operator option. 

C.I 4.1 General for Loosely Coupled Options 

C.I 4.1 .1 Actions at the AGCF at the service invocation side 

The service is invoked during a stable 2 party call (without any waiting/held call) using the Register Recall. Figure C.3 
illustrates the message sequence between the AGCF and the AS. 

On receipt of a NOTIFY request reporting a flash-hook event, the AGCF performs the following actions unless an 
explicit indication that the HOLD service is not provisioned to the user has been previously received as part of the 
profile delivery procedure: 

• Request the media gateway to play a dial tone on the physical and collect digits. 

• Send a re-INVITE request to place the current call on hold. 

On receipt of the dialled digits, the AGCF opens a new dialogue by sending an INVITE request with the following 
elements: 

• The dialled digits used as a Request-URI. 

• An SDP Offer for a voice call. 
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The AGCF then requests the media gateway to perform the following actions: 

• monitor the flash-hook event; 

• set the stream-mode of the ephemeral termination to "inactive"; and 

• waits for a n incoming SIP message. 

On receipt of 180 (Ringing) without P-Early-Media header or with a P-Early-Media header set to a value different from 
"sendonly" or from "sendreceive", the AGCF performs the following actions: 

• Request the media gateway to play a ringback tone. 

On receipt of 180 (Ringing) or 183 (Session Progress) with a P-Early-Media header set to "sendonly" or "sendreceive", 
the AGCF performs the following actions: 

• Request the media gateway to modify the configuration of the ephemeral termination so as to ensure that the 
end user will perceive early media. 

On receipt of an SDP Answer in a 200 (OK) or in one of the above provisional responses, the AGCF performs the 
following actions: 

• Request the media gateway to modify the Remote Descriptor of the ephemeral termination associated with the 
physical termination representing the analogue line. 

On receipt of a re-INVITE request requesting a call to be placed on hold, the AS applies the procedures described in 
TS 124 610 [8]. 

C. 1 4. 1 .2 Actions at the AS at the service invocation side 

Support of this service requires that all outgoing and incoming calls to the served user be handled by the same AS. 

On receipt of a service code command requesting a three party conference, the AS may check that this request is 
compatible with subscription data held in the user profile. If the user is not entitled to use this service, the AS interacts 
with an MRFC is order to play an announcement to the invoker and sends a negative response to the re-INVITE request. 

On receipt of a re-INVITE request with an SDP "a=sendonly" attribute, the AS may interact with an MRFC in order to 
play an announcement to the held party, in accordance with TS 124 628 [6]. 
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Figure C.3: Initiating a 3-Party call 

C.14.1 .3 Actions at the VGW at the service invocation side 

The service is invoked during a stable 2 party call (without any waiting/held call) using the Register Recall. Figure C.3 
illustrates the message sequence between the VGW and the AS. 

On receipt of a flash-hook event, the VGW performs the following actions unless an explicit indication that the HOLD 
service is not provisioned to the user has been previously received as part of the profile delivery procedure: 

• Play a dial tone on the physical and collect digits. 

• Send a re-INVITE request to place the current call on hold. 
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On receipt of the dialled digits, the VGW opens a new dialogue by sending an INVITE request with the following 
elements: 

• The dialled digits used as a Request-URL 

• An SDP Offer for a voice call. 

The VGW then perform the following actions: 

• monitor the flash-hook event; 

• set the stream-mode of the IP media termination to "inactive"; and 

• waits for an incoming SIP message. 

On receipt of 180 (Ringing) without P-Early-Media header or with a P-Early-Media header set to a value different from 
"sendonly" or from "sendreceive", the VGW performs the following actions: 

• Play a ringback tone. 

On receipt of 180 (Ringing) or 183 (Session Progress) with a P-Early-Media header set to "sendonly" or "sendreceive", 
the VGW performs the following actions: 

• Modify the configuration of the IP media termination so as to ensure that the end user will perceive early 
media. 

On receipt of an SDP Answer in a 200 (OK) or in one of the above provisional responses, the VGW performs the 
following actions: 

• Modify the IP media termination associated with the physical termination representing the analogue line. 

On receipt of a re-INVITE request requesting a call to be placed on hold, the AS applies the procedures described in 

TS 124 610 [8]. 

Processing of the switching order command depends on whether loose or tight coupling procedures are applied between 
the VGW and the AS. Moreover, in loose coupling case, two methods can be used: with the INVITE method, described 
in clause C.14.2, and with the REFER method, described in clause C.14.2A. Figure C.4 illustrates the loose coupling 
case with the INVITE method while figure C.5 illustrates the loose coupling case with the REFER method. The tight 
coupling case is described in clause C.14.3. 

C.14.2 Loose coupling Optioni with INVITE method 
C. 14.2.1 Actions at the AGCF at the invoking side 

The AGCF evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received from the internal MGC component does not match any known feature, the AGCF ignores 
the feature code and optionally request the media gateway to play an error tone or an announcement to the served user. 

As a network option the AGCF can evaluate a Switch Order Command based on a provisioned mapping table to correct 
a preceding Switch Order Command that was wrong. 

If the SOC indicates that the user wishes to establish a 3-party conference with the held parties, the AGCF performs the 
following actions unless an explicit indication that the 3PTY service is not provisioned to the user has been previously 
received as part of the profile delivery procedure: 

• Request the media gateway to: 

Add a termination to the current context based on SDP information associated with the held party. 
Monitor the flash-hook event. 
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• Send a re-INVITE request towards the first held party (i.e. the party that was already held when the flash-hook 
event was detected). The re-INVITE request is built as follows: 

The Request URI is set to the held party's identity. 

The SDP description is set to a=sendrecv. The address and port are set according to the contents of the 
local descriptor of the new termination. 

• Send a re-INVITE request towards the second held party (i.e. the party that has been held for the purpose of 
collecting the Switch Order Command). The re-INVITE request is built as follows: 

The Request URI is set to the held party's identity. 

The SDP description is set to a=sendrecv. 

Once the 3-party call is established with the waiting party, processing of the flash-hook event is similar to the call 
waiting service. If SOC indicates that the served user wishes to reject one of the parties, the AGCF performs the 
following actions: 

• Send a BYE request towards the held party. 

• Request the media gateway to: 

Remove the corresponding ephemeral termination. 
Monitor the flash-hook event. 

C. 14.2.2 Actions at the Originating AS at tine invoking side 

On receipt of a re-INVITE request with an SDP attribute "sendonly", the AS may interact with an MRFC in order to 
play an announcement to the held party, in accordance with TS 124 628 [6]. 

On receipt of a re-INVITE request with the SDP attribute "sendrecv", the AS interacts with the MRFC to stop any 
ongoing announcement. 

On receipt of a BYE request, the AS releases the dialogue with the associated party. 
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Figure C.4: 3PTY with INVITE method 

C.1 4.2.3 Actions at the VGW at the invoking side 

The VGW evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received does not match any known feature, the VGW ignores the feature code and optionally play 
an error tone or an announcement to the served user. 

If the SOC indicates that the user wishes to establish a 3-party conference with the held parties. The VGW performs the 
following actions unless an explicit indication that the 3PTY service is not provisioned to the user has been previously 
received as part of the profile delivery procedure: 

• The VGW: 

Add a termination to the current context based on SDP information associated with the held party. 
Monitor the flash-hook event. 
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• Send a re-INVITE request towards the first held party (i.e. the party that was already held when the flash-hook 
event was detected). The re-INVITE request is built as follows: 

The Request URI is set to the held party's identity. 

The SDP description is set to a=sendrecv. The address and port are set according to the IP media 
termination. 

• Send a re-INVITE request towards the second held party (i.e. the party that has been held for the purpose of 
collecting the Switch Order Command). The re-INVITE request is built as follows: 

The Request URI is set to the held party's identity. 

The SDP description is set to a=sendrecv. 

Once the 3-party call is established with the waiting party, processing of the flash-hook event is similar to the call 
waiting service. If SOC indicates that the served user wishes to reject one of the parties, the VGW performs the 
following actions: 

• Send a BYE request towards the held party. 

• The VGW: 

Remove the corresponding IP media termination. 
Monitor the flash-hook event. 

C.14.2A Loose coupling Option 2 with REFER method 
C.14.2A.1 Actions at the AGCF at the invoking side 

The AGCF evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received from the internal MGC component does not match any known feature, the AGCF ignores 
the feature code and optionally request the media gateway to play an error tone or an announcement to the served user. 

As a network option the AGCF can evaluate a Switch Order Command based on a provisioned mapping table to correct 
a preceding Switch Order Command that was wrong. 

If the SOC indicates that the user wishes to establish a 3-party conference with the held parties, the AGCF performs the 
following actions unless an explicit indication that the 3PTY service is not provisioned to the user has been previously 
received as part of the profile delivery procedure: 

• Request the media gateway to: 

Add a termination to the current context based on SDP information associated with the held party. 
Monitor the flash-hook event. 

• Send an initial INVITE with the To and the Request-URI containing the Conference bridge URI provisioned in 
the AGCF. 

• Send a REFER request within the existing dialog with user B with the Refer-To header containing the 
Conference bridge contact URI and the dialog associated with the B party. The ReferredBy header field is set 
to the served user's identity. 

• Send a REFER request within the existing dialog with user C with the Refer-To header containing the 
Conference bridge contact URI and the dialog associated with the C party. The ReferredBy header field is set 
to the served user's identity. 

NOTE: The REFER sent is built as specified in RFC 3515 [i.4] without any body. Unlike specified in 
RFC 3515 [i.4] the terminal will not receive any NOTIFY (see RFC 4488 [i.3]). 
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When the SIP end-point receives 202 ACCEPTED response to each sent REFER request, it: 

• performs conference estabhshment notification; 

• considers only the call established with the conference bridge as active. 

The SIP end-point will receive a BYE message in both call established. 

Once the 3 -party call is established with the waiting party, processing of the flash-hook event is similar to the call 
waiting service. If SOC indicates that the served user wishes to reject one of the parties, the AGCF performs the 
following actions: 

• Send a BYE request towards the held party. 

• Request the media gateway to: 

Remove the corresponding ephemeral termination. 
Monitor the flash-hook event. 

C.14.2A.2 Actions at the Originating AS at tine invoking side 

Upon reception of the INVITE addressed to the conference bridge, the AS forwards to the MRFC the INVITE request 
with SDP offer populated with user information. 

Upon reception of the first REFER, the AS: 

• Sends an INVITE message to the bridge with SDP offer populated with first held party information. 

• Sends a re-INVITE request towards the first held party (i.e. the party that was already held when the 
flash-hook event was detected). The re-INVITE request is built as follows: 

The Request URI is set to the held party's identity. 

The SDP description is set to a=sendrecv. The address and port are set according to the contents of the 
local descriptor of the new termination. 

• Sends a BYE message to the served-user for end his call with the first held party. 
Upon reception of the other REFER, the AS: 

• Sends an INVITE message with SDP offer populated with the second held party information. 

• Sends a re-INVITE request towards the second held party (i.e. the party that has been held for the purpose of 
collecting the Switch Order Command). The re-INVITE request is built as follows: 

The Request URI is set to the held party's identity. 

The SDP description is set to a=sendrecv. 

• Sends a BYE message to the served-user for end his call with the second held party. 
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Figure C.5: 3PTY with REFER method 

C.14.2A.3 Actions at the VGW at the invoking side 

The VGW evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received does not match any known feature, the VGW ignores the feature code and optionally play 
an error tone or an announcement to the served user. 

If the SOC indicates that the user wishes to establish a 3-party conference with the held parties, the VGW performs the 
following actions unless an explicit indication that the 3PTY service is not provisioned to the user has been previously 
received as part of the profile delivery procedure: 

• The VGW: 

Add a termination to the current context based on SDP information associated with the held party. 
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Monitor the flash-hook event. 



• Send an initial INVITE with the To and the Request-URl containing the Conference bridge URl provisioned in 
the VGW. 

• Send a REFER request within the existing dialog with user B with the Refer-To header containing the 
Conference bridge contact URl and the dialog associated with the B party. The ReferredBy header field is set 
to the served user's identity. 

• Send a REFER request within the existing dialog with user C with the Refer-To header containing the 
Conference bridge contact URl and the dialog associated with the C party. The ReferredBy header field is set 
to the served user's identity. 

NOTE: The REFER sent is built as specified in RFC 3515 [i.4] without any body. Unlike specified in 
RFC 3515 [i.4] the terminal will not receive any NOTIFY (see RFC 4488 [i.3]). 

When the SIP end-point receives 202 ACCEPTED response to each sent REFER request, it: 

• performs conference establishment notification; 

• consider only the call established with the conference bridge as active. 

The SIP end-point will receive a BYE message in both call established. 

Once the 3-party call is established with the waiting party, processing of the flash-hook event is similar to the call 
waiting service. If SOC indicates that the served user wishes to reject one of the parties, the VGW performs the 
following actions: 

• Send a BYE request towards the held party. 

• The VGW proceed with the following procedures: 

Remove the corresponding IP media termination. 
Monitor the flash-hook event. 

C.14.2B Loose coupling Option 3 by sending INVITE request with 
URl list 

C.14.2B.1 Actions at the AGCF at the invoking side 

The AGCF evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received does not match any known feature, the AGCF ignores the feature code and optionally to 
play an error tone or an announcement to the served user. Or initiate an announcement due to the procedures described 
within TS 124 628 [6]. 

As a network option the AGCF can evaluate a Switch Order Command based on a provisioned mapping table to correct 
a preceding Switch Order Command that was wrong. 

If the SOC indicates that the user wishes to establish a 3-party conference with the held parties the AGCF performs the 
following actions unless an explicit indication that the 3PTY service is not provisioned to the user has been previously 
received as part of the profile delivery procedure: 

AGCF creates a conference and invites user B and user C to the conference by sending an INVITE to the Conference 
Factory URl and including URl list in the INVITE request, AGCF indicates the certain dialogs which be re-used for this 
conference in the uri list by ? mechanism. 
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INVITE CONF AS 

To: CONF AS 

From : A 

Require: recipient-list-invite 

Content-Type : application/resource-lists+xml 
Content -Disposition: recipient -list 

<?xml version="l. 0" encoding="UTF-8" ?> 
<resource- lists xmlns="urn: ietf :params :xml :ns : resource- lists" 
xmlns : cp="urn: ietf :params :xml :ns : copyControl" > 
<list> 
<entry uri="B?Call-ID=la&From=A%3Btag%3Da&To=B%3Btag%3Db" cp : copyControl="to"/> 
<entry uri="C?Call-ID=2a&From=A%3Btag%3Da&To=C%3Btag%3Dc" cp : copyControl="to"/> 
</list> 
< /resource- list s> 

Once the 3 -party call is established with the waiting party, processing of the flash-hook event is similar to the call 
waiting service. If SOC indicates that the served user wishes to reject one of the parties, the AGCF performs the 
following actions: 

• Send a BYE request towards the Conference Server. 

• Send a BYE request towards on the held dialog of the party that should be disconnected. 

• Send a Re-INVITE on the other held party to reactivate that dialog. 

• Monitor the flash-hook event. 

C.14.2B.2 Actions at the Originating AS at tine involving side 

AS verifies if the dialogs in URI list matches to a partial dialog which AS already involved. In the case of a match the 
AS use this dialog ID information to send re-INVITE request to UA-B and UA-C in the partial dialogs between the AS 
and the invited users in order to connect the media of the invited users to the MRFP. 
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Figure C.6: Loose coupling 3PTY with INVITE method 

C.14.2B.3 Actions at the VGW at the invoking side 

The AGCF evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received does not match any known feature, the AGCF ignores the feature code and optionally to 
play an error tone or an announcement to the served user. Or initiate an announcement due to the procedures described 
within TS 124 628 [6]. 

As a network option the AVGW can evaluate a Switch Order Command based on a provisioned mapping table to 
correct a preceding Switch Order Command that was wrong. 
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If the SOC indicates that the user wishes to establish a 3-party conference with the held parties the AGCF performs the 
following actions unless an explicit indication that the 3PTY service is not provisioned to the user has been previously 
received as part of the profile delivery procedure: 

VGW creates a conference and invites user B and user C to the conference by sending an INVITE to the Conference 
Factory URI and including URI list in the INVITE request, VGW indicates the certain dialogs which be re-used for this 
conference in the uri list by ? mechanism. 

INVITE CONF AS 

To: CONF AS 

From : A 

Require: recipient-list-invite 

Content-Type : application/resource-lists+xml 
Content -Disposition: recipient -list 

<?xml version="l . 0" encoding="UTF-8" ?> 
<resource- lists xmlns="urn: ietf :params :xml :ns : resource- lists" 
xmlns : cp="urn: ietf :params :xml :ns : copyControl" > 
<list> 
<entry uri="B?Call-ID=la&From=A%3Btag%3Da&To=B%3Btag%3Db" cp : copyControl="to"/> 
< entry uri="C?Call-ID=2a&From=A%3Btag%3Da&To=C%3Btag%3Dc" cp : copyControl="to"/> 
</list> 
< /resource- list s> 

Once the 3-party call is established with the waiting party, processing of the flash-hook event is similar to the call 
waiting service. If SOC indicates that the served user wishes to reject one of the parties, the AGCF performs the 
following actions: 

• Send a BYE request towards the Conference Server. 

• Send a BYE request towards on the held dialog of the party that should be disconnected. 

• Send a Re-INVITE on the other held party to reactivate that dialog. 

• Monitor the flash-hook event. 

C.14.3 General for Tight coupling 

C. 14.3.1 Actions at the AGCF at the originating side 

On receipt of a notification of Register RECALL from the AGCF, the AGCF opens a new dialogue (D3) and sends an 
INVITE (flash) to an originating AS. This INVITE includes the following: 

• The Request URI is structured as follows: 

A user part containing "flash". 

A domain name that together with the user part provides sufficient information for the AS Network to 
forward the request to the appropriate AS, based on Initial Filter Criteria stored in the user profile, 
e.g. "flash@pes.operator.com" 

• A From header containing the public identity of the line on which the RECALL occurred. 

• An SDP offer for a speech call. 

The AGCF now awaits receipt of a 484 Address Incomplete from the originating AS, and when received the AGCF 
takes the following actions: 

• Requests the A-MGW to play Dial Tone and collect one digit. 

• Sends an INVITE (D3) containing this single digit (as this is a Recall sequence with more than one active 
dialogue) and await receipt of 200 OK (Invite) or a failure response code. This INVITE is built in the same 
way as the previous INVITE except that the dialled digit replaces "flash". 
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The AGCF then awaits a re-INVITE (D2) with the SDP of a Media Server in the AS Network (acting as a 3 party 
bridge) and when received it takes the following actions: 

• Sends an instruction to the A-MGW to change the address to which RTP packets are sent and from which they 
are received (e.g. it modifies the H.248 Remote Descriptor). 

Sends a 200 OK (Invite) to the AS, awaits receipt of a BYE to end dialogue D3, and when this is received it sends a 200 
OK (Bye). 

C. 14.3.2 Actions at the Originating AS at tine originating side 

On receipt of an INVITE (flash) (D3) the AS takes the following actions: 

• Sends a 484 Address Incomplete response to the AGCF and awaits receipt of an ACK. 

• Awaits receipt of an INVITE (D3) with a single digit and when this is received sends a 200 OK (Invite) to the 
AGCF and awaits receipt of the ACK. 

• Sends a Re-INVITE (D2) with the SDP of a Media Server (acting as a 3 party bridge) to the AGCF, awaits a 
200 OK (Invite) and when this is received it sends an ACK followed by a BYE (D3). 

• It then awaits a 200 OK (Bye). 
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Figure C.7: 3PTY Call Establishment for tight coupling 
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C. 14.3.3 Actions at the VGW at the originating side 

On receipt of a notification of Register RECALL from the VGW, the VGW opens a new dialogue (D3) and sends an 
INVITE (flash) to an originating AS. This INVITE includes the following: 

• The Request URI is structured as follows: 

A user part containing "flash". 

A domain name that together with the user part provides sufficient information for the AS Network to 
forward the request to the appropriate AS, based on Initial Filter Criteria stored in the user profile, 
e.g. flash@pes.operator.com . 

• A From header containing the public identity of the Une on which the RECALL occurred. 

• An SDP offer for a speech call. 

The VGW now awaits receipt of a 484 Address Incomplete from the originating AS, and when received the VGW takes 
the following actions: 

• Play Dial Tone and collect one digit. 

• Sends an INVITE (D3) containing this single digit (as this is a Recall sequence with more than one active 
dialogue) and await receipt of 200 OK (Invite) or a failure response code. This INVITE is built in the same 
way as the previous INVITE except that the dialled digit replaces "flash". 

The VGW then awaits a re-INVITE (D2) with the SDP of a Media Server in the AS Network (acting as a 3 party 
bridge) and when received it takes the following actions: 

• Change the address to which RTP packets are sent and from which they are received. 

Sends a 200 OK (Invite) to the AS, awaits receipt of a BYE to end dialogue D3, and when this is received it sends a 200 
OK (Bye). 



C.15 Repeat Last Call 

C.15.1 AGCF at the served user side 

The Repeat Last Call service is invoked using a service code command. On receipt of this service code command, the 
AGCF builds an INVITE request as described in clause C.l. 

C.15.2 AS at the served user side 

Implementation of this service assumes that the AS providing the service is involved in all outgoing calls to the served 
user. It is the responsibility of the network operator to configure the appropriate Initial Filter Criteria in the user profile. 
The AS keeps track of the last incoming call to each served user it manages. 

When receiving the service code command that identifies the Repeat Last Call service, the AS acts as a B2BUA and 
establishes a new call leg to the last called party (i.e. it sends an INVITE messages towards this last called party as if the 
number had been dialled again by the served user). 

C.15.3 VGW at the served user side 

The Repeat Last Call service is invoked using a service code command. On receipt of this service code command, the 
VGW builds an INVITE request as described in clause C. 1 . 



ETSI 



1 27 ETSI TS 1 83 043 V3.4.1 (201 1 -04) 



C.16 Call Hold 

C.16.1 Option 1 (Loose Coupling) 

C.16. 1.1 Actions at the AGCF at the service invocation side 

The service is invoked during a stable 2 party call using the Register Recall. 

The AGCF monitors the flash-hook event unless an explicit indication that the Hold service is not provisioned to the 
user has been previously received as part of the profile delivery procedure. 

On receipt of a NOTIFY request reporting a flash hook event, the AGCF performs the following actions: 

• Monitor the flash-hook event. 

• Send a re INVITE request to place the current call on hold. 

On receipt of a NOTIFY request reporting a flash hook event, the AGCF performs the following actions: 

• Send a re INVITE request to resume the call on hold. 

• Monitor the flash-hook event. 

On receipt of a re INVITE request requesting a call to be placed on hold, the AS applies the procedures described in 
TS 124 610 [8]. 

As a network option the AS of the invoking UE initiates the procedures for the provision of an announcement to the 
held user in accordance with TS 124 628 [6]. 

C. 1 6. 1 .2 Actions at the AS at the service invocation side 

On receipt of a re INVITE request requesting a call to be placed on hold, the AS applies the procedures described in 
TS 124 610 [8]. 

As a network option the AS of the invoking UE initiates the procedures for the provision of an announcement to the 
held user in accordance with TS 124 628 [6]. 

C.I 6.1 .3 Actions at the VGW at the service invocation side 

The service is invoked during a stable 2 party call using the Register Recall. 

The VGW monitors the flash-hook event unless an explicit indication that the Hold service is not provisioned to the 
user has been previously received as part of the profile delivery procedure. 

On receipt of a NOTIFY request reporting a flash hook event, the VGW performs the following actions: 

• Monitor the flash-hook event. 

• Send a re INVITE request to place the current call on hold. 

On receipt of a NOTIFY request reporting a flash hook event, the VGW performs the following actions: 

• Send a re INVITE request to resume the call on hold. 

• Monitor the flash-hook event. 

On receipt of a re INVITE request requesting a call to be placed on hold, the AS applies the procedures described in 
TS 124 610 [8]. 

As a network option the AS of the invoking UE initiates the procedures for the provision of an announcement to the 
held user in accordance with TS 124 628 [6]. 
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C.16.2 Option 2 (Tight Coupling) 

C. 16.2.1 Actions at the AGCF at the service invocation side 

The service is invoked during a stable 2 party call using the Register Recall. 

The handling of the resulting Feature Request in the AGCF is according to clause B.4.2.2.3. The AGCF only reports the 
flash-hook as a trigger to the AS which has to take and co-ordinate all following actions dependent on the current 
service configuration. 

As a network option the AS of the invoking UE initiates the procedures for the provision of an announcement to the 
held user in accordance with TS 124 628 [6]. 

C.I 6.2.2 Actions at the AS at the service invocation side 

For tight coupling procedures the control of flash-hook invoked services is fully under control of the Application 
Server. As a consequence the AGCF/VGW only reports the flash-hook as a trigger to the AS which has to take and 
co-ordinate all following actions dependent on the current service configuration. 

In the context of 3 way call services the initial INVITE (flash) as described in clause B.4.2.2.3 only triggers the AS to 
place the current call on hold. Hold and resumption scenarios are specified in the supplementary service specific clauses 
of annex C. 

As a network option the AS of the invoking UE initiates the procedures for the provision of an announcement to the 
held user in accordance with TS 124 628 [6]. 

C.I 6.2.3 Actions at the VGW at the service invocation side 

The service is invoked during a stable 2 party call using the Register Recall. 

The handling of the resulting Feature Request in the VGW is according to clause B.4.2.2.3. The VGW only reports the 
flash-hook as a trigger to the AS which has to take and co-ordinate all following actions dependent on the current 
service configuration. 

As a network option the AS of the invoking UE initiates the procedures for the provision of an announcement to the 
held user in accordance with TS 124 628 [6]. 

C. 1 7 Call Toggle/Broker Call Service 

C.I 7.1 General 

C.I 7. 1.1 Actions at the AGCF at the service invocation side 

The service is invoked having an active call and a held call using the Register Recall. 
The AGCF monitors the flash-hook event. 

C.I 7.1 .2 Actions at the VGW at the service invocation side 

The service is invoked having an active call and a held call using the Register Recall. 
The VGW monitors the flash-hook event. 
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C.17.2 Option 1 (Loose coupling) 
C. 17.2.1 Actions at the AGCF 

On receipt of a NOTIFY request reporting a flash hook event, the AGCF performs the following actions: 

• Set the stream mode of the ephemeral termination to inactive. 

• Apply a dial tone. 

• Collect a switching order command. 

The AGCF evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received from the internal MGC component does not match any known feature, the AGCF ignores 
the feature code and optionally request the media gateway to play an error tone or an announcement to the served user. 

If the SOC indicates that the user wishes to toggle the active and the held parties the AGCF performs the following 
actions unless an explicit indication that the Call Toggle service is not provisioned for this user has been previously 
received as part of the profile delivery procedure: 

• Send a re INVITE request towards the active party. The re INVITE request is built as follows: 

The Request URI is set to the active party's identity. 

The SDP description for the active media stream is set to a=sendonly. 

• Send a re-INVITE request towards the former held party. The re-INVITE request is built as follows: 

The Request-URI is set to the held party's identity. 

The SDP description for the active media stream is set to a=sendrecv. 

• Request the media gateway to: 

Modify the Remote Descriptor of the ephemeral termination according to the SDP information associated 
with the held party. 

Monitor the flash-hook event. 

C.I 7.2.2 Actions at tine AS at tine terminating side 

On receipt of a re-INVITE request with a SDP attribute "sendonly", the AS as a network option interacts with an MRFC 
is order to play an announcement to the held party, in accordance with TS 124 628 [6]. 

On receipt of a re-INVITE request with the SDP attribute "sendrecv", the AS interacts with the MRFC to stop any 
ongoing announcement. 

C.I 7.2.3 Actions at tine VGW 

On receipt of a NOTIFY request reporting a flash hook event, the VGW performs the following actions: 

• Set the stream mode of the IP media termination to inactive. 

• Apply a dial tone. 

• Collect a switching order command. 

The VGW evaluates the Switch Order Command based on a provisioned mapping table. 

If the feature code received does not match any known feature, the VGW ignores the feature code and optionally play 
an error tone or an announcement to the served user. 
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If the SOC indicates that the user wishes to toggle the active and the held parties the VGW performs the following 
actions unless an explicit indication that the Call Toggle service is not provisioned for this user has been previously 
received as part of the profile delivery procedure: 

• Send a re INVITE request towards the active party. The re INVITE request is built as follows: 

The Request URI is set to the active party's identity. 

The SDP description for the active media stream is set to a=sendonly. 

• Send a re-INVITE request towards the former held party. The re-INVITE request is built as follows: 

The Request-URI is set to the held party's identity. 

The SDP description for the active media stream is set to a=sendrecv. 

• The VGW perform the following procedures: 

Modify the IP media termination according to the SDP information associated with the held party. 
Monitor the flash-hook event. 

C.17.3 Option 2 (Tight coupling) 
C. 17.3.1 Actions at the AGCF 

Dependent on the network configuration the service can be invoked by the user: 

• via flash-hook; or 

• via flash-hook plus additional digits to be collected at AGCF. 

On receipt of a notification of Register RECALL the AGCF opens a new dialogue (D3) and sends an INVITE (flash) to 
an originating AS. This INVITE includes the following: 

• The Request URI is structured as follows: 

A user part containing "flash" 

NOTE: In networks where no explicit SOC is collected, a preconfigured SOC is used to populate the user part. 

A domain name that together with the user part provides sufficient information for the AS Network to 
forward the request to the appropriate AS, based on Initial Filter Criteria stored in the user profile, 
e.g. "flash@pes.operator.com" 

• A From header containing the public identity of the line on which the RECALL occurred. 

• An SDP offer for a speech call. 

If the network configuration requires that additional digits have to be collected to identify the desired service, then the 
AGCF now awaits receipt of a 484 Address Incomplete from the originating AS, and when received the AGCF takes 
the following actions: 

• Requests the A-MGW to play Dial Tone and collect the requested number of digits. 

• Sends an INVITE (D3) containing the collected digits (as this is a Recall sequence with more than one active 
dialogue) and await receipt of 200 OK (Invite) or a failure response code. This INVITE is built in the same 
way as the previous INVITE except that the dialled digits replaces "flash". 

The AGCF then awaits a re-INVITE (D2) with the SDP of the resumed former held party and when received it takes the 
following actions: 

• Sends an instruction to the A-MGW to change the address to which RTP packets are sent and from which they 
are received (e.g. it modifies the H.248 Remote Descriptor). 



£75/ 



1 31 ETSI TS 1 83 043 V3.4.1 (201 1 -04) 

• Sends a 200 OK (Invite) to the AS, awaits receipt of a BYE to end dialogue D3, and when this is received it 
sends a 200 OK (Bye). 

C.1 7.3.2 Actions at the Originating AS at tine originating side 

In networks where an explicit SoC is collected the AS on receipt of an INVITE (flash) (D3) takes the following actions: 

• Sends a 484 Address Incomplete response to the AGCF/VGW and awaits receipt of an ACK. 

• Awaits receipt of an INVITE (D3) with the requested number of digits and when this is received sends a 
200 OK (Invite) to the AGCF/VGW and awaits receipt of the ACK. 

The AS evaluates the Switch Order Command based on the current call configuration and issues appropriate re-INVITE 
messages putting the former active party on hold and resuming the former held party. 

If more than one party has been placed on hold or is in a CW condition it depends on the network operator which of the 
held parties will be selected for resuming. E.g. a rotating list algorithm might apply for service invocation by flash-hook 
from the user. The maximum number of calls between Call Toggle is possible should be specified by the network 
operator. 

The AS interacts with an MRFC is order to play and stop announcements to held party, in accordance with 
TS 124 628 [6]. 

C.1 7.3.3 Actions at tine VGW 

The VGW sends a re-INVITE request to the Application Server on the active call, built as follows: 

• The Request URI is structured as follows: 

A user part containing a provisioned prefix followed by the switching order command without the start 
and finish fields. 

NOTE: In networks where no explicit SOC is collected, a preconfigured SOC is used to populate the user part. 

• A domain name that provides sufficient information to the S-CSCF to forward the INVITE request to the 
appropriate AS, based on Initial Filter Criteria stored in the user profile, 

e.g. SOC- "SO (SR SI)"@pes.operator.com. 

• A P-Asserted-Identity containing the public identity of the subscriber issuing the switching control command. 

• An SDP offer for a voice call. 

The VGW modifies the stream mode according to the SDP information received in re-INVITE messages sent by the 
Application Server. 



C.1 8 Completion of Communications to Busy Subscriber 
(CCBS) and Completion of Communications by No 
Reply (CCNR) 

0.18.1 Actions at the Originating AGOF 

For invoking and revoking of the call completion services, announcement procedures according to TS 124 628 [6] and 
inband-interaction procedures should be used. 

The "m" parameter in the request line of the received REFER or INVITE request in the AGCF/VGW is ignored or may 
be used to select a ring pattern conforming to a "distinctive ring" signal. 
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C.18.2 Actions at the Originating AS 

The AS implements the procedures described in TS 124 642 [47], clause 4.5.4.2. 

C.18.3 Actions at the Terminating AS 

The AS implements the procedures described in TS 124 642 [47], clause 4.5.4.3. 

C.1 8.4 Actions at the Terminating AGCF 

Basic call procedures according to clauses 5, 6 and 7 of the present document shall apply. 

C.1 8.5 Actions at the Originating VGW 

For invoking and revoking of the call completion services, announcement procedures according to TS 124 628 [6] and 
inband-interaction procedures should be used. 

The "m" parameter in the request line of the received REFER or INVITE request in the AGCF/VGW is ignored or may 
be used to select a ring pattern conforming to a "distinctive ring" signal. 

C.1 8.6 Actions at the Terminating VGW 

Basic call procedures according to clauses 5 and 6 of the present document shall apply. 
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Annex D (normative): 

Mapping between SIP and the subscriber line protocol 



D.1 Introduction 



This annex describes the mapping between SIP messages received by an AGCF or a VGW acting as a UE and the 
messages of the subscriber line protocol defined in ES 200 659-3 [10]. 



D.2 Call Setup message 



This message is used to send information related to an incoming call. e.g. Calling Line Identification Presentation 
(CLIP) and related services. 

This message is built by the AGCF or the VGW on receipt of an initial INVITE request. 

The AGCF requests the media gateways to send this message over the analogue line using the Display Data Block 
parameter of the Display With Alerting signal of the andisp package defined in ITU-T Recommendation H. 248. 23 [13]. 

The AGCF or VGW populates the message parameters as described in table D.l, based on the contents of the INVITE 
message and local configuration data. 

Table D.l : Call set-up message parameters 



Parameter type 


0/M 


Populating rules 


Date and Time 





Set from local clock (see note 1 ) 


Calling Line Identity 

or 

Reason for absence of Calling Line Identity 


M 


Set according to the contents of the "From" header or 

"P-Asserted-ldentity" header dependent on national operator 

requirements. 

Or 

Set from "Privacy" header (see note 2). 


Called Line Identity 





"P-Called-Party-ld" header. 


Calling Party Name 

or 

Reason for absence of Calling Party Name 





Set according to the "Display-Name" in the "From" header or 

"P-Asserted-ldentity" header dependent on national operator 

requirements 

Or 

"Privacy" header (see note 2). 


Complementary Calling Line Identity 





Setting of this parameter is based on operator specific rules. 


Call type 





Setting of this parameter is based on operator specific rules. 


First Called Line Identity 





Set according to the "hi-targeted-to-uri " in the first entry in the 

"History-Info" header 

Absent if the "Privacy" header set to "history". 


Number of IVIessages 





Setting of this parameter is based on operator specific rules. 


Type of Forwarded call 





Set according to the "Cause" parameter associated with the 
"hi-targeted-to-uri" in the last entry of the "History-lndo" header. 
Absent if the "Privacy" header is set to "history". 


Type of Calling User 





Set from the cpc parameter of the P-Asserted-ldentity header 
Absent if the "Privacy" header set to "header". 


Redirecting Number 





Set according to the "hi-targeted-to-uri" in the last entry in the 

"History-Info" 

Absent if the "Privacy" header set to "history". 


Network Provider Identity 





Setting of this parameter is based on operator specific rules. 


Carrier Identity 





Setting of this parameter is based on operator specific rules. 


Selection of Terminal Function 





Setting of this parameter is based on operator specific rules. 


Display Information 





May be set from the contents of the message body. 


Service Information 





May be set from the contents of the message body. 
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Parameter type 


0/M 


Populating rules 


Extension for network operator use 





Setting of this parameter is based on operator specific rules. 


NOTE 1 : The AGCF and the VGW shall support an appropriate clock synchronization mechanism. 

NOTE 2: If the "Privacy" header is included and set to "id" or "user" or "header", the Reason for Absence is set to 

"Private" (0101 0000). If the "P-Asserted-ldentity" header and the "From" header are absent, the Reason for 

Absence is set to "unavailable" (01 00 1 1 1 1 ). 



D.3 Message Waiting Indicator message 

This message type is used to handle information related to messages in a message system. 

This message is built by the AGCF or the VGW on receipt of a NOTIFY request reporting the "message-summary" 
event. 

The AGCF requests the media gateways to send this message over the analogue line using the Data Block parameter of 
the Generic Data Signalling signal of the andisp package defined in ITU-T Recommendation H. 248. 23 [13]. The value 
of the TAS parameter is provisioned in the AGCF or MGF, per media gateway or per line. 

The AGCF or the VGW populates the message parameters as described in table D.2, using the information contained in 
NOTIFY requests reporting the "message-summary" event and local configuration data. 

Table D.2: Message Waiting Indicator message parameters 



Parameter type 


0/M 


Populating rules 


Date and Time 





Set from local clock (see note). 


Calling Line Identity 

or 

Reason for absence of Calling Line Identity 





Set according to the contents of the "P-Asserted-ld" header 

Or 

Privacy header. 


Calling Party Name 

or 

Reason for absence of Calling Party Name 





Set according to the "P-Asserted-ld" header 

Or 

"Privacy" header. 


Visual Indicator 


M 


Set to "FF"H if the "Messages-Waiting" header is set to "yes". 


Message Identification 





Set according to the "Message-ID" header. 


Last IVIessage CLI 





"From" header associated with the last message. 


Complementary Date and Time 





"Date" header associated with the last message. 


Complementary Calling Line Identity 





Setting of this parameter is based on operator specific rules. 


Number of IVIessages 





Set according to the "Voice-Message" header. 


Type of Calling User 





Setting of this parameter is based on operator specific rules. 


Network Provider Identity 





Setting of this parameter is based on operator specific rules. 


Selection of Terminal Function 





Setting of this parameter is based on operator specific rules. 


Display Information 





May be set from the contents of the message body. 


Extension for network operator use 





Setting of this parameter is based on operator specific rules. 


NOTE: The AGCF and the UE shall support an appropriate clock synchronization mechanism. 





D.4 Advice of Charge message 

This message is used to send information related to the charge of a call. 

This message is built by the AGCF or the VGW on receipt of a SIP message that contain information defined in 

TS 124 647 [7]. 

The AGCF or the VGW populates the message parameters as described in table D.3, based on information defined in 
TS 124 647 [7] and local configuration data. 
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Table D.3: Advice Of Charge message parameters 



Parameter type 


0/M 


Populated From 


Date and Time 





Set from local clock (see note). 


Calling Line Identity 

or 

Reason for absence of Calling Line 

Identity 





Setting of this parameter is based on operator specific rules. 


Called line identity 





Setting of this parameter is based on operator specific rules. 


Complementary Calling Line Identity 





Setting of this parameter is based on operator specific rules. 


Charge 


M 


Set from the "recorded-charges" element defined in TS 124 647 [7]. 


Additional Charge 





Setting of this parameter is based on operator specific rules. 


Duration of the call 





Setting of this parameter is based on operator specific rules. 


Network Provider Identity 





Setting of this parameter is based on operator specific rules. 


Carrier Identity 





Setting of this parameter is based on operator specific rules. 


Selection of Terminal Function 





Setting of this parameter is based on operator specific rules. 


Display information 





Set from the value of the "billing-id" element defined in TS 1 24 647 [7]. 


Extension for network operator use 





Setting of this parameter is based on operator specific rules. 


NOTE: The AGCF and the VGW shall support an appropriate clock synchronization mechanism. 
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Annex E (normative): 

AOC - Extended XML schema (version 2) 



E.1 General 



This annex defines the XML Schema to be used for providing the charging information described in clause C.2 to the 
served user. 

The extensions introduced (versus the TS 124 647 [7] AOC XML schema) are indicated by the present document 
Change Note comment. In addition, the naming of the extension elements uses the prefix "pes". 

The MIME type (see clause E.2) used to provide the charging information requested by the served user shall be coded 
as described in clause E.3. 



E.2 IVIIIVIE Type Definition 
E.2.1 Introduction 

This clause defines the MIME type for "application/vnd.etsi.aoc+xml". An AOC information XML Document can be 
identified with this media type. 

NOTE: TS 124 647 [7] includes the lANA Registration template for "application/vnd.etsi.aoc+xml". 

E.2.2 Syntax 

The following optional parameters are defined: 

• "charset": the parameter has identical semantics to the charset parameter of the "application/xml" media type 
as specified in RFC 3023 [45]. 

• "sv" or "schema version": the syntax for the "sv" or "schemaversion" parameter is specified in table E.l. 

Table E.l : Syntax of the "sv" or "schemaversion" parameter 

m-parameter /= {"sv" / "schemaversion") EQUAL LDQUOT [ sv-value-list ] RDQUOT 

sv-value-list = sv-value-range *{ "," sv-value ) 

sv-value-range = sv-value [ "-" sv-value ] 

sv-value = number / token 

number = 1*DIGIT [ " . " 1*DIGIT ] 



The BNF for m-parameter is taken from RFC 3261 [38] and modified accordingly. 



E.2.3 Operation 



The encoding considerations for "application/vnd.etsi.aoc+xml" are identical to those of "application/xml" as described 
in RFC 3023 [45]. 

The "sv" or "schemaversion" parameter's value is used to indicate: 

• the versions of the AOC information XML schema that can be used to validate the AOC information XML 
body (if the MIME type and parameter are present in the Content-Type header); or 
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• the accepted versions of the AOC information XML body (if the MIME type and parameter are present in the 
Accept header). If the "sv" or "schema version" parameter's value is empty, no versions of the AOC 
information XML schema are supported. 

If the "sv" and "schema version" parameter are absent, it shall be assumed that version 1 of the XML Schema for the 
AOC information XML body is supported. 



E.3 AOC Extended XML Schema 

The .xsd file is contained in archive ts_183043v030401p0.zip which accompanies the present document. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="http : //uri . etsi . org/ngn/params/xml/simservs/aoc " 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="http : //uri .etsi .org/ngn/params/xml/simservs/aoc " elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" version="2" > 

<xs : import namespace="http : //www.w3 .org/XML/ 1998 /namespace" 
schemaLocation="http : //www.w3 . org/2 01/xml .xsd"/> 
<xs : annotation> 

<xs : documentation xml : lang="en"> 

XML Schema Definition to the charging information related to the Advice of Charge simulation 
service . 

</xs : documentation> 
</xs : annotation> 

<xs:element name="aoc-extended" type="aocType"/> 
<xs : complexType name="aocType" > 
<xs : sequence> 

<!--TS 183 043 Change Note: extended optional element has been added bellow- -> 
<xs : element name="pes-transitioning-behaviour" type="pes-transitioning-behaviourType" 
minOccurs= " " / > 

<!--TS 183 043 Change Note: "aoc-s"type, maxOccurs="unbounded" has been added--> 
<xs:element name="aoc-s" type="aoc-sType" minOccurs="0" maxOccurs="unbounded"/> 
<xs:element name="aoc-d" type="aoc-dType" minOccurs="0"/> 
<xs: element name="aoc-e" type="aoc-eType" minOccurs="0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs :complexType> 

<!-- xs : sequence is changed to xs:choice --> 
<xs : complexType name="aoc-sType" > 
<xs : choice> 

<xs:element name="special-arrangement" type="xs : token"/> 
<xs: element name=" charged- items" type=" charged- itemsType"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : choice> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs : complexType name="aoc-dType" > 
<xs : sequence> 

<xs: element name=" charging- info" type=" charging- infoType"/> 
<xs : element name=" recorded- charges" type="recorded-chargesType"/> 
<xs:element name="billing-id" type="billind-idType" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name="aoc-eType" > 
<xs : sequence> 

<xs : element name=" recorded- charges" type="recorded-chargesType"/> 
<xs:element name="billing-id" type="billind-idType" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name=" charged- itemsType" > 
<xs : sequence> 

<!--TS 183 043 Change Note: extended optional element has been added below --> 
<xs:element name="pes_aoc-s_phase_duration" type="timeType" minOccurs=" 0"/> 
<xs:element name="basic" type="basicType" minOccurs=" 0"/> 

<xs : element name="communication-attempt" type="communication-attemptType" 
minOccurs= " " / > 

<xs:element name="communication-setup" type="communication-setupType" minOccurs="0"/> 

<xs: element name=" services" type="servicesType" minOccurs="0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
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</xs : sequence> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name="basicType" > 
<xs : sequence> 

<xs:element name="price-time" type="price-timeType" minOccurs="0" 
maxOccur s = " unbounded " / > 

<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs=" 0"/> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0"/> 
<xs:element name="special-code" type="xs : token" minOccurs="0"/> 
<xs:element name="not-available" type="emptyType" minOccurs=" 0"/> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="communication-attemptType" > 
<xs : sequence> 

<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs="0"/> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0"/> 
<xs:element name="special-code" type="xs : token" minOccurs="0"/> 
<xs:element name="not-available" type="emptyType" minOccurs=" 0"/> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="communication-setupType" > 
<xs : sequence> 

<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs="0"/> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0"/> 
<xs:element name="special-code" type="xs : token" minOccurs="0"/> 
<xs:element name="not-available" type="emptyType" minOccurs=" 0"/> 
</xs : sequence > 
</xs : complexType > 

<xs : complexType name="servicesType" > 
<xs : sequence> 

<xs:element name="price-time" type="price-timeType" minOccurs=" 0"/> 
<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs=" 0"/> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0"/> 
<xs:element name="special-code" type="xs : token" minOccurs="0"/> 
<xs:element name="not-available" type="emptyType" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 

<!-- length-time-unit: type="timeType" {another possibilty is to keep length-time-unit with 
type="xs : duration" ) 

granularity: type="timeType" {another possibility is type="xs : duration" ) 
{xs : duration: the minimum resolution is second) 
- - > 

<xs : complexType name="price-timeType" > 
<xs : sequence> 

<xs: element name=" currency- id" type="xs : token" minOccurs="0"/> 

<!-- The currency- id shall be coded according to ISO 4217 [3] or set to the value 
"UNIT" for the sending of charging units. --> 

<xs:element name=" currency- amount" type="xs : decimal" minOccurs="0"/> 
<xs:element name="length-time-unit" type="timeType" minOccurs="0"/> 
<xs:element name=" charging- type" type=" charging- typeType" minOccurs=" 0"/> 
<xs:element name= "granularity" type="timeType" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name=" currency- id- amountType" > 
<xs : sequence> 

<xs:element name=" currency- id" type="xs : token" minOccurs="0"/> 

<!-- The currency-id shall be coded according to ISO 4217 [3] or set to the value 
"UNIT" for the sending of charging units. --> 

<xs:element name=" currency- amount" type="xs : decimal" minOccurs="0"/> 
</xs : sequence> 
</xs :complexType> 

<I-- timeType is represented with time-unit {unsigned int) * scale {enum) --> 
<xs : complexType name="timeType"> 
<xs : sequence> 

<xs: element name=" time-unit" type="xs :unsignedInt"/> 
<xs:element name="scale" type="scaleType"/> 
</xs : sequence > 
</xs : complexType > 
<xs : simpleType name="scaleType" > 

<xs : restriction base="xs : token" > 

<xs : enumeration value="one-hundreth- second" /> 

<xs : enumeration value= "one- tenth- second" /> 

<xs : enumeration value= "one- second" /> 

<xs : enumeration value=" ten-seconds" /> 

<xs : enumeration value= "one-minute" /> 

<xs : enumeration value="one-hour"/> 

<xs : enumeration value="twenty-four-hours"/> 
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</xs : restriction> 
</xs : simpleType> 

<!-- end of timeType definition --> 
<xs : complexType name="emptyType"> 
<xs : complexContent> 

<xs : restriction base="xs : anyType"/> 
</xs : complexContent> 
</xs : complexType> 
<!-- simplified --> 

<xs : simpleType name=" charging- infoType" > 
<xs : restriction base="xs : token" > 

<xs : enumeration value="total"/> 
<xs : enumeration value=" subtotal "/> 
</xs : restriction> 
</xs : simpleType> 

<!-- xs : sequence is changed to xs: choice --> 
<xs : complexType name=" recorded- chargesType" > 
<xs : choice> 

<xs : element name="recorded-currency-units" type= "currency- id-amountType"/> 
<xs:element name="f ree-charge" type="emptyType"/> 
<xs:element name="not-available" type="emptyType"/> 
</xs : choice> 
</xs : complexType> 

<xs : simpleType name="billind-idType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value= "normal- charging" /> 
<xs : enumeration value=" reverse- charging" /> 
<xs : enumeration value=" credit- card" /> 
<xs : enumeration value="cfu"/> 
<xs : enumeration value="cfb"/> 
<xs : enumeration value="cfnr"/> 
<xs : enumeration value="cd"/> 
<xs : enumeration value="ct"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name=" charging- typeType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value="step-functon"/> 
<xs : enumeration value="continuous"/> 
</xs : restriction> 
</xs : simpleType> 

<!--TS 183 043 Change Note: simpleType definition for the optional 
"pes-transitioning-behaviourType" added below --> 

<xs : simpleType name="pes-transitioning-behaviourType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value=" Immediate" /> 
<xs : enumeration value="Continuous"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 
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Annex F (normative): 
Overlap Sending 

This annex describes the handling of Overlap Sending according to EN 300 403-1 [41], clause 5.1.3. 



F.O General 



Three methods of signalling are described in this annex: 

Clause F. 1 describes sending of Invite with determining the end of address signalling. 



• 



• Clause F.2 describes a signalling procedure without determining the end of address signalling using a multiple 
INVITE method. 

• Clause F.3 describes a signalling procedure without determining the end of address signalling using a 
In-Dialog method. 

The collection of Digits at the originating VGW/AGCF shall be controlled using the following timers: 

• T-FirstDigit timer: The amount of time allowed for the user to enter the first digit. 

• T-InterDigit timer: The amount of time allowed for the user to enter each subsequent digit. 

• Additional timers which are per signalling method are described in the relevant clauses F. 1, F.2 and F.3. 
The Ta3 timer used in clauses F.2 and F.3, shall be provisioned to a value that is greater than the T-InterDigit timer. 
Clause F.4 provides a table containing the complete list of Timers. 

F.1 Sending of Invite with determining the end of address 
signalling 

F.1 .1 Actions at the originating VGW/AGCF 



VGW/ 
AGCF 



-1. Off-Hook»- 

—2. Diait 1- 
—3. Digit n- 



4. iNViTE 
(n Digits) 



Figure F.1 : Receipt of Digit information at thie originating VGW/AGCF 

After initiating the normal incoming PSTN call establishment procedures, determining the end of address signalling and 
selecting to route the call to the IMS domain, the originating VGW/AGCF sends the initial INVITE. The initial INVITE 
contains all digits, i.e. en-bloc sending. 

The end of address signalling is determined by the earlier of the following criteria: 

a) by receipt of the maximum number of digits used in the national numbering plan; or 

b) by analysis of the called party number to indicate that a sufficient number of digits has been received to route 
the call to the called party. This could be achieved by analysis of a provisioned dial plan; or 
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c) by observing that timer Tal has expired after the receipt of the latest received address digit and the minimum 
number of digits required for routing the call have been received. 

If the end of the address signalling is determined in accordance with criteria a) or b), the timer Ta2 is started when 
INVITE is sent. 

The AGCF/VGW can contain a configurable digit map which is used to analyse the received address digits. This digit 
map can be used to identify the required number of digits to be entered for a particular digit sequence. The procedures 
for Digit maps are described within clause 7.3.1.3.1.1. 

Even in the absence of a digit map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCF/VGW 
shall contain a configurable parameter indicating the minimum number of digits expected in the sequence of Called 
party number information elements before a Request-URI is constructed and an INVITE request sent. The minimum 
number could be zero. 

F.1 .2 Actions at the terminating VGW/AGCF 

No action with regard to overlap is needed. 
DDI is out of scope of the present document. 



F.2 multiple INVITE Overlap Dialling Procedures 
(Optional) 

F.2.1 .1 Actions at the originating VGW/AGCF 

F. 2.1 .1 .1 Sending of INVITE without determining the end of address signalling 

On detection of the off -hook event, the AGCF/VGW will return dial tone, if required by the tone option. 

1) As a network option, the originating VGW/AGCF may send INVITE requests without determining the end of 
address signalling. If the originating VGW/AGCF sends an INVITE request before the end of address 
signalling is determined, the originating VGW/AGCF: 

uses the SIP precondition extension within the INVITE request; according to TS 124 229 [4]; 

starts timer Ta2; and 

is prepared to process further incoming digits as described below; 

is prepared to handle incoming SIP 404 or 484 error responses as detailed in this clause. 

2) On receipt of fresh address information from the originating side, the originating VGW/AGCF: 

stops timer Ta3 (if it is running); 

sends an INVITE request complying to the following: 

■ the INVITE request uses the SIP preconditions extension; 

■ the INVITE request includes all digits received so far for this call in the Request-URI. 

if subsequent address information is received after the SIP 404 or 484 error response has been received, 
the INVITE request additionally includes the digits received; 

restarts Ta2. 

If timer Ta2 has expired, the originating VGW/AGCF cancels the call. 

On receipt of a 180 Ringing or 183 Provisional Response, the originating VGW/AGCF stops Ta2. 
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3) As a network option the Timer Ta4 can be used, in this case the following procedure applies starting with the 
first digit received by the AGCF/VGW: 

start timer Ta4 with receiving the first dialled Digit; 

collect all digits received; 

at expiry of timer Ta4 the initial INVITE is sent out; 

proceeds as described under 1 ; 

if further digits are needed then the AGCF/VGW shall collect further digits until min length has been 
reached. 

NOTE: The AGCF/VGW contains a configurable parameter indicating the minimum number of digits expected in 
the sequence of Called party number information elements before a Request-URI is constructed and an 
INVITE request sent. The minimum number could be zero. 

As a network Option the first INVITE can be sent with the detection of the "off-hook" event. 

The Ta4 shall not be used if the INVITE has to be sent immediately because e.g. the hotline feature is provided to the 
originating user. 

On receipt of a 404 Not Found or 484 Address Incomplete response while Ta2 is running, the originating VGW/AGCF 
starts timer Ta3, if there are no other pending INVITE transactions for the corresponding call. 

At the receipt of fresh address information, or a SIP 180, 183 provisional responses, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF stops Ta2 and Ta3. As a network optionTimer Ta4 may be started (the communication is then 
proceeding as described in the rest of this clause). 

The originating VGW/AGCF clears as described in clause 7.3.1.3.1.2 the call if Ta3 expires. 

Option a) Overlap with T34 Timer 



Off Hook 



Digit 1 



Digit 2 



Digits 



Digit 4 



Digit n 



Ring Tone 



AGCFA/GW 



x-CSCF 



^ 



y 



T. 



J INVITE Cseq 1 



180 Ringing Cseq 1 



Figure F.2: Overlap with T34 Timer- no transaction is pending 
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Figure F.3: Overlap with Ta4 Timer one transaction is pending 
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Option b) Overlap with Digit Map 
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Figure F.4: Overlap with digit map 
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Option c) Overlap with Digit Map and T^^ Timer 
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Figure F.5: Overlap with digit map and Ta4 timer 
digit map matchied before 1^4 expiry 
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Figure F.6: Overlap with digit map and Ta4 timer 
digit map matched after J^^ expiry 
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Figure F.7: Overlap with Ta4 Timer - using the option to send 
the first INVITE at the off-hook event 



F.2.2 Actions at the terminating VGW/AGCF 



No action with regard to overlap is needed. 
DDI is out of scope of the present document. 



F.3 In-Dialog IVIethod (Optional) 

F.3.1 Actions at the originating VGW/AGCF 

F.3.1 .1 Sending of INVITE without determining the end of address signalling 

On detection of the off -hook event, the AGCFA'^GW will return dial tone, if required by the tone option. 

1) As a network option, the originating VGW/AGCF may send INVITE requests without determining the end of 
address signalling. If the AGCFA^GW sends an INVITE request before the end of address signalling is 
determined, the AGCF/VGW shall: 

use the SIP precondition extension within the INVITE request, according to TS 124 229 [4]; 

starts timer Ta2; and 

be prepared to process farther incoming digits as described below; 

be prepared to handle incoming SIP 484 (Address Incomplete) responses; 

on receipt of 404 Not Found or 484 Address Incomplete start timer Ta3; 

on receipt of 183 Provisional Response without P-Early-Media header authorizing early media, stop Ta2 
and start Ta3. 
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NOTE 1: Based on the network solution the reception of 484 can be avoided. This assumes that an AS behaving as 
B2BUA is collecting the digits starting with the first INVITE. 

2) On receipt of a new Address information, the AGCF/VGW shall: 

stop timer Ta3 (if it is running); 

if an early dialog has been established and a response has been received for any previously sent SIP 
INFO request, send a SIP INFO request including the additional digits for this call and start timer Ta2; 

if no response has been received for the previous SIP INFO request, the AGCF/VGW shall wait for the 
response and then apply the procedures in the previous bullet to send the new address information. If 
more than one digit is received while the AGCF/VGW is waiting for the response for the previous SIP 
INFO request, all digits within shall be combined; 

if an early dialog has not been established, wait for a final error response for the previous INVITE and 
send an INVITE request including all digits received so far for this call in the Request-URI and start Ta2 
if Ta4 is not running. The SIP INVITE request shall include the same Call ID and From tag as the 
previous SIP INVITE request for the call. 

NOTE 2: The encoding of the digits within the SIP INFO request is described in clause F.3.4. 

At the receipt of a SIP 200 OK (INFO) the originating VGW/AGCF shall stop Ta2 and start Ta3. 

At the receipt of a SIP 180, 183 provisional response with P-Early-Media header authorizing early media, or a SIP 
200 OK (INVITE), the originating VGW/AGCF shall stop Ta2 and Ta3. 

As a network option the Timer T.^^ can be used, in this case the following procedure applies starting with the first digit 
received by the AGCF/VGW: 

• start timer T,^^ with receiving the first address information; 

• collect all digits received; 

• at expiry of timer T^^^ the initial INVITE is sent out as described under 1); or 

• if further digits are needed then the AGCF/VGW shall collect further digits until min length has been reached. 

NOTE 3: The AGCF/VGW contains a configurable parameter indicating the minimum number of digits expected in 
the sequence of Called party number information elements before a Request-URI is constructed and an 
INVITE request sent. The minimum number could be zero. 

As a network Option the first INVITE can be sent with the receipt of the "off-hook" event. 

The Ta4 shall not be used if the INVITE has to be sent immediately because e.g. the hotline feature is provided to the 
originating user. 

The originating VGW/AGCF clears as described in clause 7.3.1.3.1.2 the call if Ta3 expires. 
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Option a) Overlap with T^^ Timer 
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Figure F.8: Overlap with 1^4 Timer- no transaction is pending 
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Figure F.9: Overlap with T34 Timer no transaction is pending 
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Option b) Overlap with Digit Map 
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Figure F.10: Overlap with digit map 
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Option c) Overlap with Digit Map and T^^ Timer 
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Figure F.1 1 : Overlap with digit map and Ta4 timer 
digit map matched before Ta4 expiry 
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Figure F.I 2: Overlap with digit map and J^^ timer 
digit map matched after J^^ expiry 
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Figure F.13: Overlap with 1^4 Timer - using the option to send 
the first INVITE at the off-hook event 



F.3.2 Actions at the terminating VGW/AGCF 

No action with regard to overlap is needed. 
DDI is out of scope of the present document. 

F.3.3 Procedures at the overlap signalling AS (Optional) 

With receiving the initial INVITE the AS shall query the attached routing HSS or database to find the destination. 

In case of an indication that more digits are needed the AS creates an early dialog by sending a 183 (Session Progress) 
response. The AS shall also start a T-InterDigit timer (typically 10 s tol5 s) If the T-InterDigit timer expires then the 
call shall be released by the AS. 

When additional address information is received within SIP INFO Requests, the AS SHALL add them to the previously 
received digits, and use them for HSS/database routing queries in order to being able to forward the call. 

When enough address information has been collected to forward the call to the appropriate destination, the AS SHALL 
create a SIP INVITE request, which contains all the received address digits, and forward it towards the destination. 

In cases where it is identified that the call shall be forwarded to networks not supporting overlap in-dialog signalling, 
the AS shall perform en-bloc conversion. If the minimum number of digits required for routing the call have been 
received, the AS shall start a short timer Tal (typically 4 s to 6 s) and wait for subsequent SIP INFO Requests carrying 
additional request information. When the Tal timer expires, the AS SHALL create a SIP INVITE request, which 
contains all the received address digits, and forward it towards the destination. 
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Figure F.14: IN-Dialog Overlap Signalling with included AS at the originating leg 

1. INVITE: Sent from the originating network towards a S-CSCF. 

2. INVITE: Forwarded to the AS acting as a B2BUA that will collect the digits. 

3. Lookup: The AS is connected to all databases needed for the routing decision like the HSS, ENUM/DNS for 
Transit or such a Number Portability data base. 

4. Lookup procedure within the Database to get more information. 

5. The DB sends back that there is not sufficient information on which the call can be routed. 

6. 183 (Call Progress) to start the early dialog for the Digit collection via IN-Dialog. 

7. 183. 

8. INFO; additional address information is sent towards the S-CSCF. 

9. INFO: AS collects and merge the digits to and request now the whole number existing from the digits received 
within the INVITE and the digits received within the INFO. 

10. Query of new number. 

1 1 . Lookup procedure within the database to get more information. 
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12. The DB sends back that there is not sufficient information on which the call can be routed. 

13. Send a 200 OK (INFO) back to that the digits are received. 

14. 200 OK (INFO). 

15. INFO; additional address information is sent towards the S-CSCF. 

16. INFO: AS collects and merge the digits to and request now the whole number existing from the digits received 
within the INVITE and the digits received within the INFO. 

17. Query of new number. 

18. Lookup procedure within the database to get more information. 

19. The DB sends back that there are sufficient digits received. 

20. Send a 200 OK (INFO) back to that the digits are received. 

21. 200 OK (INFO). 

22. INVITE will be now forwarded back to the S-CSCF with the complete number/IP address of the terminating 
P-CSCF. 

23. INVITE sent toward the terminating network. 

24. 180 (Ringing)received from the terminating network. 

25 . 180 (Ringing) S-CSCF - AS . 

26. 180 (Ringing) AS - S-CSCF. 

27. 180 (Ringing) S-CSCF- towards originating network. 

F.3.4 Overlap digit message body 
F.3.4.1 Scope 

This clause defines a message body that shall be used for sending additional digits, which have not previously been 
sent, in SIP INFO messages when the in-dialog method is used for overlap dialling. 

The support of this message body is a network option. 

NOTE: The contents of clause F.3.4 will be inherited in the Release 8 version of TS 129 163 [32], annex G. As a 
consequence clause F.3.4 will be removed in the NGN Release 3 document which will in general refer to 
3GPP Release 8 specifications. 

F.3.4.2 IVIIIVIEtype 

The message body defined in the present annex is registered at lANA as "application/x-session-info" MIME type. 

If the message body is embedded in SIP INFO messages, the Content-Type header shall be set to 
"application/x-session-info" and the Content-Disposition header shall be set to "signal" with the handling parameter set 
to "optional". 

F.3.4.3 ABNF 

x-session-inf o = SubsequentDigit 

SubsequentDigit = "SubsequentDigit" HCOLON phonedigits 

phonedigits = 1* {HEXDIG / "*" / "#") 

HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 
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F.4 Timers 



Table F.I : Timers for interworking 



Symbol 


Time-out 
value 


Cause for initiation 


Normal termination 


At expiry 


T-FlrstDlgit 


1 s to 99 s 
(default=60 s) 


Upon start of dial tone 
injection 


On receipt of the first dialed 
digit 


Release Call 


T-interDlgit 


1 s to 1 5 s 
(default=10s) 


Upon receipt of a new address 
message 


Upon receipt of subsequent 
address message or 1 80 
Ringing or 183 Session 
Progress with P-Early Media 
header authorizing early 
media 


a) Disable Digit Receiver; 

b) if Ta3 is not running then 
Release Call 


Ta1 


4 s to 6 s 
(default of 4 s) 
(see note 1 ) 


When last address information 
is received and the minimum 
number of digits required for 
routing the call have been 
received. 


At the receipt of fresh address 
information. 


Send INVITE 


Ta2 

(Multiple 
Invite) 


1 s to 1 5 s 
(see notes 2 
and 4) 


When INVITE is sent. 


On reception of 180 Ringing, 
or 183 Session Progress, or 
404 Not Found or 484 
Address Incomplete for an 
INVITE transaction for which 
Ta2is running, or 200 OK 
(INVITE). 


Release Call 


Ta2 
(in-Dlalog) 


1 s to 1 5 s 
(see notes 2 
and 4) 


When INVITE is sent or when 
INFO is sent. 


On reception of 180 Ringing, 
or 183 Session Progress, or 
404 Not Found or 484 
Address Incomplete for an 
INVITE transaction for which 
Ta2 is running, or 200 OK 
(INVITE) or 200 OK (INFO). 


Release Call 


Ta3 

(Multiple 
invite) 


4 s to 20 s 
(default of 15 s) 
(see note 3) 


On receipt of 404 Not Found 
or 484 Address Incomplete if 
there are no other pending 
INVITE transactions for the 
corresponding call. 


At the receipt of fresh address 
information 


Release call 


Ta3 
(In-Dlalog) 


4 s to 20 s 
(default of 15 s) 
(see note 3) 


On receipt of 404 Not Found 
or 484 Address Incomplete if 
there are no other pending 
INVITE transactions for the 
corresponding call. 
On receipt of 200 OK (INFO), 
or 183 Session Progress 
without early media 
authorization. 


At the receipt of fresh address 
information or 180 Ringing or 
183 with P-Early-Media 
header authorizing early 
media or 200 OK (INVITE) 


Release call 


Ta4 


0,5 s to -4 s 


On receipt of the initial 
address information. 


At expiry 


Send INVITE 


NOTE 1 : This timer is used in clause F.I when overlap signalling is received from access line and converted to en-block 

signalling at the AGCF/VGW. 
NOTE 2: This timer is used in clauses F.2 and F.3 to wait for an 404/484 response. In addition clause F.3 uses this 

timer for: 

a) to wait for an 183 response to an INVITE; 

b) to wait for a 200 OK (INFO) response. 

NOTE 3: This timer is known as the "SIP dialog protection timer". This timer is only used where the AGCF/VGW is 

configured to send INVITE before end of address signalling is determined. The Ta3 timer shall be greater than 
the T-lnterDigit timer. 

NOTE 4: The value of timer Ta2 may vary beyond these limits, e.g. as a result of called party number analysis. 
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Annex G (informative): 

Digit collection in MRF after receipt of flash-hook in the tight 

coupling model 

G.1 Introduction 

In the case where the tight couphng model is used for flash-hook invoked services, this annex describes the optional use 
of the MRF for collection of dialled digits and provision of dial tone. 

G.2 Management of dial tone and digit collection in the 
MRF 

• Upon receipt of a Feature-Request resulting from the detection of a flash-hook event the Feature Manager of 
the AGCF/VGWrequests the SIP UA to create a new dialogue and to send an INVITE (flash) request built as 
specified in clause B. 4. 2. 2. 3. 2 (i.e. including an SDP offer for a voice call) to the AS. 

As a network option, the AGCF/VGW may also send a re-INVITE request over the existing dialogue with an SDP 
requesting the B-Party to be put on hold (i.e. a=sendOnly), prior to sending the INVITE request creating the new 
dialogue In such cases the AGCF/VGW waits for the 200 OK response to the re-INVITE request before sending the 
new INVITE request. 

On receipt of an INVITE request from an AGCF/VGW indicating detection of a flash-hook event the AS may perform 
the following actions: 

• Create a new dialogue to MRF to arrange the bearers to connect the MRF and the A-Party (i.e. the party having 
originated the flash-hook event). 

• Request the MRF to provide dial tone to the caller and to start inband collection of dialled digits. 

The AS may also arrange for an announcement to be played to the held party via an MRF as described in annex C for 
the specific services. 

Collected digits are then reported to the AS which has to interpret them according to the current service configuration as 
e.g. dialled terminating subscriber number in a Three Party scenario or as a switching order command e.g. during Call 
Toggle Service. 

It is the responsibility of the AS to close the dialogue to the MRF after completion of the evaluation of the reported 

digits. 
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Annex H (normative): 
Support of PSTN modem calls 

H.1 Introduction 

This annex describes the details for emulation of PSTN modem calls for support of services Voiceband Data in general 
and Fax over IP in particular. The following flavours of support are taken into consideration: 

• optional support of Voiceband Data over IP (VBDoIP) according to V.152 [48]; 

• optional support of Fax over IP (FoIP) according to T.38 [49]. 

H.2 Voiceband Data over IP emulation service according 
to V.152 

H.2.1 Introduction 

The support of Voiceband Data (VBD) over IP according V.152 [48] is optional, but recommended as default for the 
emulation of PSTN modem calls. 

NOTE: See also clause 8 in TR 183 072 [i.5]. 

H.2.2 IP transport services for V.152 VBD 

V. 152 VBD defines different transport services, driven e.g. by Grade of Service (GoS) conditions of the IP network or 
business models for PSTN emulation services. 

The V.152-capable PES endpoint should explicitly indicate the requested IP transport service, if the PES endpoint want 
to use the capabilities for enhancing the transport reliability, in his SDP offer and table H. 1 . 

NOTE: See also clause 7.1.1 in TR 183 072 [i.5]. 

This is achieved by the inclusion of an explicit VBD codec in its list of codecs, as described in V.152 [48]. 

H.2.2.1 Examples 

H.2.2. 1 .1 Example 1 "Non-assured VBD mode" 

Example signalling and SDP encoding for the SDP Offer may be found: 

• for "revised SDP Offer/ Answer" : see e.g. table 8 in V. 152 [48]; 

• for "legacy SDP Offer/Answer": see e.g. table 7 in V.152 [48]. 
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Another example for "legacy SDP Offer/ Answer" would be: 



Table H.I : Example SDP encoding - Offer in Legacy SDP Offer/Answer syntax 



SDP encoding (shortened SDP description) 


Comments 


v=0 

o=- IN IP4 blabla. domain 

S=H.248 Context 

t = 

c=IN IP4 11.9.20.01 

m=audio 33906 RTP/AVP 8 101 111 

a=rtpmap: 101 telephone-event/8000 

a=rtpmap:lll PCMA/8000 

a=gpmd:lll vbd=yes 


In the example, static payload type '8' and 
dynamic payload type '111' each represent the 
encoding format 'PCIVIA'. The payload type '8' is 
not associated with VBD. The payload type '111' 
(PCMA) relates to the V.I 52 VBD codec. 
The packetization times for Audio and VBD are 
both unspecified, thus default values would be 
supposed. 

Network telephone events using payload type 
'101' (RFC 4733 [17] packets). 



H.2.2.1 .2 Example 2 "Assured VBD mode, using RTP packet redundancy" 

Example signalling and SDP encoding for the SDP Offer may be found: 

• for "revised SDP Offer/ Answer" : see e.g. table 14 in V. 152 [48]; 

• for "legacy SDP Offer/Answer": see e.g. table 13 in V.152 [48]. 

H.2.2.1 .3 Example 3 "Assured VBD mode, using Forward Error Correction" 

Example signalling and SDP encoding for the SDP Offer may be found: 

• for "revised SDP Offer/ Answer" : see e.g. table 16 in V. 152 [48]; 

• for "legacy SDP Offer/Answer": see e.g. table 15 in V.152 [48]. 

H.2.3 Transitioning between Audio and VBD IVIode 

Transitioning between Audio mode and VBD mode is possible in both directions and (in general) can occur multiple 
times within a single call/session (see also clause 7.6 in TR 183 072 [i.5]). The procedures for transitioning between 
these two modes of operation are described in clause 10 of V.152 [48]. 

H.3 Fax over IP relay service according to T.38 
H.3.1 Introduction 

The support of Fax over IP according T.38 [49] is optional. In order to improve the interoperability of T.38 fax 
gateways (i.e. PSTN-to-IP gateways with T.38 support, but also T.38 Internet-aware fax devices (lAF)) connected to a 
VGW or a MGW which conform to the present document shall support a minimum set of requirements selected out of 
the range presented in T.38. 

NOTE: Additional guidance for the support of T.38 and V. 152 at H.248-based gateway control interfaces is 

available in the ARGW H.248 Profile TS 183 002 [5]. However, TS 183 002 [5] is not considering the 
codec negotiation process at application (call) control interfaces like SIP/SDP. 
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H.3.2 T.38 stimuli detection (by PES endpoint) and Transitioning 
between Audio / T.38 IVIodes 

• Connection establishment related aspects: 

The gateway should initiate a voice call with audio codec and should reserve resources for T.38 service, 
and, upon fax detection, the switch-over to T.38 fax capabilities is triggered. 

• Transitioning between Audio mode and T.38 mode is possible in both directions and (in general) can occur 
multiple times within a single call/session. The procedures for transitioning between these two modes are 
described in T.38 [49]. 

• During this switchover and the facsimile call the voice channel shall be muted. The voice channel may be used 
again once the end of facsimile transmission is detected (note). 

• Alternately, some implementations may choose to replace the voice channel with a facsimile channel (note). 

NOTE: See also note at the end of clause 6.1 in TR 183 072 [i.5]). Reuse or replacement of the "voice channel" 
may require further studies with respect to autonomous transitioning behaviour and conditions on initial 
SIP/SDP Offer/ Answer exchange. E.g. T.38 Version 4 supports autonomous transitioning 
(see clause D.2.2.4.3 in [49]). 

H.3.3 T.38 configuration details 

NOTE: General aspects of T.38 configurations are outlined in clause 7.1.2.1 in TR 183 072 [i.5]. 

It is recommended to explicitly indicate and negotiate at least the following minimum set of T.38 configuration 
parameters: 

• T.38 protocol version ("there are five versions (0 to 4) up to now"); 

• T.38 transport mode ("there are the three modes UDTPL/UDP, TPKT/TCP, RTP/UDP"); 

• T.38 data rate management method; 

• T.38 error correction; 

• T.38 fax transcoding ("none", "MMR" or "JBIG"); and 

• T.38 supported modem ("primarily due to V.34 versus non-V.34-G3FE device"). 
The following specific configuration details shall be considered by the present document: 

• T.38 transport mode: IFP packets shall be transferred by means of UDP transport applying IFP encapsulation 
in UDPTL (Facsimile UDP Transport Layer protocol). 

• Data rate management method 2: (see T.38 [49], section 8.2) shall be supported as this method is declared as 
mandatory for UDP. 

H.3.4 Control plane aspects 

• SIP/SDP: 

Generally annex D of T.38 shall apply to AGCF/VGW conforming to the present document. All 
parameters specified as an extension to SDP in T.38, clause D. 2. 1.3.1, shall be negotiated. 

NOTE: See also guideUnes by clauses 7.1.2.1, 7.1.2.2 and 8 by TR 183 072 [i.5]. 
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H.3.5 Enhancements of T.38 



The following general assumptions related to the existing text given in T.38 shall apply. The aspects are given by 
different modes of the user plane interworking function by T.38 endpoints and correspondent control plane signalling. 



H.3.5.1 T.38 Versioning 



• The VGW should support T.38 ASN.l version number 3 in order to enable transfer rates beyond 14 400 bit/s, 
e.g. support of V.34 with 33 600 bit/s. For GW offering both V.152 VBD with G.71 1 and T.38, the gateway 
based on configuration may transport V.34 in V.152 VBD with G.71 1 or stay in T.38 with fallback to 
V.17/V.29 if T.38 version 3 with V.34 is not managed by both peers. 

T.38, clause D.2.2.5 "Support of T.38A^.34G3 facsimile and fallback to T.38/G3 facsimile" shall be considered 
in case of V.34 transported facsimile traffic. 

• The VGW may support T.38 version 4, e.g. in order to indicate support of T.38 parameter "T38ModemType" . 

NOTE: It is expected that the interworking between different T.38 versions will be addressed by 

ITU-T Recommendation T.38 [49]. The default case should be the same T.38 version negotiated by both 
"T.38 endpoints". 

H.3.5. 2 T.38 mode concerning G3FE with and without V.34 modem 

There are two types of G3FE: with and without support of V.34. 

• The V.34 detection should be done on ANSam detection by the GW. 

• Principle V.34 support should be indicated by T.38 parameter "T38ModemType" if correspondent T.38 version 
would be supported. 

NOTE: The interworking details between "T.38/G3" and "T.38/V.34 G3" capable T.38 endpoints are specified by 
clause D.2.2.5 in T.38 [49]. 
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Annex I (normative): 

Gap analysis - llVIS-based PES versus support by 3GPP 

IMS 



1.1 Background 



The present document defines SIP and SDP capabilities, required for the emulation of PSTN modem calls by the IMS 
domain. These signalling capabilities are primarily subject of 3GPP specifications, resulting in a dependency of the 
present document to some 3GPP specifications (see clause 6.3). 

Purpose of this annex: explicit indication of service gaps and possible impact on network deployments. 

NOTE: This annex may be deleted again in future in case of correspondent SIP/SDP support by the referred 
3GPP specifications. 



1.2 llVIS-based PES capabilities: PSTN modem call 
support 



1.2.1 Not supported features 



Missing SDP support (see clause 6.3.5), - SDP parameters and SDP Offer/ Answer negotiation capabilities -, limits the 
usage of emulation services for PSTN modem calls in IMS-based PES installations. See table I.l. 

Table 1.1 : Feature gap with regards to PSTN modem calls 



No. 


Capability 


Support? 


Clause(s) 


1 


VBDolP pass-through service (V.152) 
for PSTN modem calls in general 


No 


6.3.1.2.1.2, 
6.3.1.2.1.3(a), 
6.3.1.2.1.4, 
H.2 


2 


VBDolP pass-through service (V.152) 

for PSTN facsimile/modem calls in particular 


No 


see No. 1 


3 


VBDolP pass-through service (V.152) 
for PSTN data/modem caWs in particular 


No 


see No. 1 


4 


VBDolP pass-through service (V.152) 
for PSTN text/modem caWs in particular 


No 


see No. 1 


5 


FolP packet-relay service (T.38) for PSTN facsimile/modem caWs 


Limited 
(notel) 


6.3.1.2.1.2, 
6.3.1.2.1.3 (b1,b2), 
6.3.1.2.1.5, 
H.3 


6 


Offering alternative media configurations VBDolP V.152 vs FolP T.38 


No 


6.3.1.2.1.3(a) 


7 


VBDolP-type specific configurations (VBD codec type, VBD transport 
mode) 


No 


see No. 1 and 
H.2.2 


8 


FolP-type specific configurations (T.38 configuration variants) 


No 


see No. 5 and 
H.3.3 


9 


Check of FolP T.38 support and required T.38 configuration in detail 
already during call establishment phase (note 2) 


No 


6.3.1.2.1.3 (b2), 
6.3.1.2.1.5 (b2), 
6.3.1.4 


10 


Individual packetization times for media configurations (e.g. between 
VoIP audio and VBDolP pass-through) 


No 


see No. 1 
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No. 


Capability 


Support? 


Clause(s) 


11 


Support of "G3-Superfax" (i.e. V.34-capable T.38) 


No 


see No. 5 and 
H.3.5.2 


12 


Fast call establishment phases (single-cycle SIP/SDP Offer/Answer) 


No 
(note 3) 


6.3.1.2 


NOTE 1 : The RFC 3362 [i.8] MIME type for T.38 is already supported (by TS 129 163 [32], TS 124 229 [4]), but 
allows only the indication of a T.38 media stream in SDP, but not any indication and negotiation of T.38 
configuration settings in detail. 

NOTE 2: Requires revised SDP Offer/Answer in general and the latent configuration capability in particular. 

NOTE 3: Efficient single cycle negotiations may be supported with revised SDP Offer/Answer, but may be not 
guaranteed with legacy SDP Offer/Answer. 



1.2.2 Impact on IMS-based PES networks 

1.2.2.1 Intra-network call 

Any service guarantees may not be provided for the services indicated in previous clause. There will be a best effort 
approach in terms of 

• a minimum FoIP packet-relay (T.38) service; and 

• a pseudo-VBDoIP pass-through (non-V.152) service. 

The best effort approach implies associated configuration management activities in all related IMS-based PES entities 
(in order to avoid different configuration settings; see e.g. also clause H.3 in T.38). 

1.2.2.2 Inter-network call 

Peering scenarios with other SIP networks may lead to incoming SIP messages with unsupported SDP. Such SDP 
elements would be ignored by the receiving SIP instances. 



1.3 IMS-based PES capabilities: other services 

None identified. 
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